[darcs-users] Re: Darcs cgi-push, preliminary implementation

[Juliusz Chroboczek]

>> Canonical "http push api", there simply isn't such thing.  What
>> I propose here is very simple api and has no significant drawbacks
>> as far as I can see.

> Out of curiosity, why not just use DAV

Warning: lengthy anti-WebDAV rant follows.  Please discard this
message straight away, and read no further.

There's no such thing as WebDAV.  RFC 2616 defines HTTP/1.1, RFC 2518
defines what I'll call ``WebDA'' (no ``V''), and RFC 3253 defines
``DeltaV'', a set of versioning extensions to WebDA.  As the term
``WebDAV'' is often used for what I call ``WebDA'', I'll call
``WebDA+V'' the combination of ``WebDA'' and ``DeltaV''.

HTTP/1.1 (RFC 2616) defines the methods GET, PUT, PUSH and DELETE.  It
has no provision for reading the contents of a directory, as it is
expected that this will be done using index files (you know,
``public_html/index.html'').  Typical server implementations are able
to generate index files dynamically, but this has no influence on the
protocol.  (2616 also defines the methods HEAD and OPTIONS, but that's
irrelevant to the discussion at hand.)

HTTP/1.1 also defines ``preconditions'' for requests, which can be
used to implement lock files.  Unfortunately, servers are allowed to
ignore preconditions, lock files thus implemented are therefore
unreliable unless you know the server implementation.

WebDA (RFC 2518) basically adds DIR to HTTP in a horribly convoluted,
extremely general way.  It does so by defining a new method, PROPFIND,
which returns arbitrary metadata about an HTTP instance
(``properties'').  One kind of property is the list of children of a
given instance (provided as XML), which is claimed to subsume the
functionality of a directory scan.

WebDA also provides locking of subtrees (both shared and exclusive
locks), but I don't know how reliable are typical implementations of
this feature.

DeltaV (RFC 3253) adds a form of versioning to WebDA.  If memory
serves, the model it uses for versioning is sequences of trees with
explicit locking, but not much beyond that; not even delta computation
can be done server-side.  I do not see how DeltaV can be useful in
practice.

> like Subversion does?

AFAIK, SVN uses a fragment of WebDA+V with a bunch of non-standard
extensions, which they implement using non-standard WebDA properties.
You cannot run a SVN client against a generic WebDA+V server.  Running
a generic WebDA client against a SVN server sort of works -- but with
mildly amusing results (such as getting multiple SVN revisions for
every WebDA commit).

In other words, the facilities provided by DeltaV appear to be too
primitive even for Subversion.

> It sounds like it would do everything you want and uses a custom
> interface.

When accessing a remote repo in read-only mode, Darcs only needs to
get files (not even directory listings are needed); hence, 2616 is
enough for read-only access to Darcs repos, and this is fully
implemented.

In order to write to a remote repo, Darcs needs to execute a remote
Darcs binary.  There is no facility for remote exec in any of the
WebDA specifications; the only way to do remote exec over HTTP is to
use a CGI, which is what Esa has implemented.

As I've stated multiple times, what I believe we need is a way to push
remotely without a remote Darcs, which is something I intend to work
on when I next have some hacking time (at least for the sftp transport).
All that we'll need for that is

  (i) a way to PUT files remotely;
  (ii) a way to atomically create a lock file.

(i) can be implemented using either sftp or stock HTTP (2616), hence
no need for WebDA.  (ii) is more tricky; I intend to implement it by
ignoring the problem, i.e. by creating lock files unsafely and
requiring the user to ensure mutual exclusion.  I don't know yet
whether it'd be useful to use either HTTP/1.1 preconditions or WebDA
locks (any opinions on the subject are welcome).

                                        Juliusz