"Delta V" is an extension to WebDAV to do versioning.
In essence, maybe one can think of WebDAV as doing a networked filesystem over the web (i.e. like AFS or NFS, but over HTTP).
Delta V (RFC 3253) adds versioning support to that filesystem.
Why would you want to do a networked filesystem over HTTP, instead of just giving it its own protocol? I haven't quite figured that out yet. It does seem that, somehow, making things go over HTTP magically makes them more interoperable. For example, as an inexperienced developer, I feel like I have a fighting chance of writing a Perl script to interact with WebDAV, whereas I'm afraid to try and write one to interact with AFS (although I'm not sure that there's any reason that one would actually be harder than the other; anyone know?).
Perhaps using HTTP allows you to bypass certain functionality that is taken care of by the web server. Like, all the technical details of sockets, etc. Web servers can call CGI scripts, which are then insulated from sockets and TCP/IP. Do others think that this is the case? Or is it actually just as easy to write a simple TCP/IP server as it is to write a CGI script, and one just seems more scary than the other.
Anyhow, although I haven't looked at Delta V yet, it struck me that with Delta V, we probably have a complete protocol for automatically interacting with a wiki's PageDatabase? as a webservice. I.e. we probably have a protocol to GET a page, to PUT a page, to get a list of all pages, to fetch a list of past revisions of a page, and to fetch a particular past revision.
So perhaps doing WikiGateway through Atom is a red herring. It's still a good thing to do, I guess, to provide interoperability with Atom clients (although, I'm still not sure why Atom is needed in the face of WebDAV; maybe as a temporary solution until WebDAV becomes more supported, and it becomes possible for "typical" users to run WebDAV servers/WebDAV-serving CGI scripts?). Perhaps WebDAV + Delta V is the ultimate InterWiki protocol.
Also, one of my goals is to separate Wiki frontends from backends, and I've always thought that leaving Wiki pages as files in the filesystem, and using CVS, would be a clean, interoperable way to do this (indeed, I think that some of OddMuse's ancestors did things this way1). Subversion is the successor to CVS, and it looks like it may implement the most important part of the DeltaV protocol.
Any thoughts as to Subversion vs. Delta V? What are the differences between them? And, which (if either) is the best contender to become the "ultimate InterWiki protocol"?
My thoughts on the relationship between wiki and WebDAV.
A wiki uses HTML Forms to allow users to edit web pages on a server. Wikis are a class of CGI programs acting as servers. Wikis support versioning.
Right now, wikis have no protocol. This means that there is no standard way for automated clients to work with wiki servers. Human users can interact via HTML forms, but each wiki has a slightly different forms-based UI. When people do write software to act as clients to wiki servers, they are reduced to screen scraping. Which is one reason why I started the WikiGateway project; to collect all this screen scraping Once and For All into a reusable library. WikiGateway will also expose standard APIs for different wiki servers, such as WikiXMLRpc?, Atom, and, someday, WebDAV.
It seems to me that Wikis and WebDAV may be a perfect match. WebDAV + Delta V is basically a protocol to formalize the operations that users perform on the PageDatabase? already, via HTML forms. WikiXMLRpc? is probably essentially a proper subset of WebDAV.
So, perhaps we should standardize on WebDAV + DeltaV as the standard for automated interaction with wiki servers. WikiGateway would serve as a go-between (proxy) to mediate between WebDAV+DeltaV clients and wiki servers which don't support WebDAV.
Subversion is the successor to CVS 2, a versioning 3 system originally meant to coordinate software developers working on the same code 4. There is already a WikiEngine? which uses a Subversion backend (SubWiki).
A Subversion client uses part of the DeltaV protocol for communicating with a remote Subversion server. However, neither one conforms completely to DeltaV, and the client also requires Subversion-specific DeltaV extensions. A Subversion client CANNOT make do with a generic DeltaV server; it requires a Subversion server.
However, a Subversion server CAN handle certain requests from a NON-SUBVERSION, generic DeltaV client! In fact, it can even handle normal WebDAV and HTTP requests, such as GET and PUT (treating the PUT as a commit to the repository). Unfortunately, Subversion does not, and will not soon, implement locking. Most WebDAV clients require the server to do locking, so the Subversion server isn't very interoperable.
So, it seems that in terms of features, neither DeltaV nor Subversion are a subset of the other. WebDAV+DeltaV includes locking6 which Subversion can't do. But, Subversion can do operations like "update" 7, which are not included in the DeltaV spec.
Luckily for us, I think that neither the DeltaV-specific operations nor the Subversion-specific operations are critical for wikis8. In fact, wikis are a lot simpler than both of these, since in wikis users generally only edit one page at a time, whereas both Subversion and DeltaV encompass the idea of operating on collections of resources.
So, I think that WebDAV+DeltaV probably will qualify as a protocol for interacting with wikis. And, I think that Subversion's limited level of support for WebDAV includes all of the operations which wikis would use anyway.
So, we're probably set. We can implement a subset of the WebDAV+DeltaV standard, and I think that Subversion servers will be able to interoperate with us anyway (i.e. maybe we can use Subversion as a backend to store the PageDatabase?, like SubWiki).
(and, by the way, is this server running Subversion? I notice that the 404 error page here says "
Apache/2.0.48 (Debian GNU/Linux) DAV/2 SVN/0.33.0 mod_python/3.0.3 Python/2.3.3 mod_ssl/2.0.48 OpenSSL/0.9.7c")