"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"?

There's a discussion of how to get WebDav and DeltaV working to make something wiki-like on WikiFeatures:WebDav. --EvanProdromou


The relationship between wiki and WebDAV

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.

WebDAV is a protocol to allow clients to edit web pages on servers. WebDAV doesn't support versioning, but WebDAV + Delta V does.

Wikis are server programs. WebDAV is a protocol. Wikis could support the WebDAV protocol, but right now they don't.

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.

How Subversion fits in

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).

In general, Subversion is not very interoperable with DeltaV, but it may become more so in the future 5. However, for our purposes, it may interoperate just fine.

Details on interoperability between Subversion, DeltaV, and wikis

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")


Wikis and other relevant tools using WebDav


Other relevant tools


See also WikiFeatures:WebDav, SubWiki





1. CvWiki and AtisWiki, although I think with AtisWiki you had an option to do it without CVS
2. although Arch sounds cool too
3. or “revision control” or “source code management”
4. i.e. to help them keep their changes in sync
5. This is a supposition; the Subversion manual seems to indicate that someone over there is looking at more interoperability between Subversion and Delta V in the future [1]
6. and other operations?
7. which tells the server to send the client any changes that have happened to the files that the client was working on since the client last checked
8. We don’t need the WebDAV LOCK operation. And, we don’t need to do fancy source code management stuff like “update”; we never need to have a collection of documents checked out a once.

Define external redirect: WikiXMLRpc SubversionWiki

EditNearLinks: WikiEngine CvWiki AtisWiki PageDatabase CategoryInterWiki OddMuse CategoryWebTechnology WebDav