Just hooked my DAV implementation up to real shared files in the Mugshot shared files feature I mentioned last week.
Unfortunately, it looks like this won't work all that well with the DAV implementations in Nautilus or Windows Explorer. Both ignore the "display name" provided by DAV, and neither have a way to provide an icon URL via DAV. They do a fine job of browsing the DAV share but the filenames and icons are all fugly.
For Nautilus I think the only real solution is to provide a tree of .desktop files instead of a tree of real files (ugh). For Windows, I think there are third-party DAV implementations that don't suck as much. For either one another option is to write a custom vfs backend / shell extension, though for Nautilus even a vfs backend requires the "virtual .desktop files" hack to override display name and icon.
btw, I think DAV would be a nice model for an API replacing gnome-vfs. The main thing DAV does is add a method called PROPFIND to http. PROPFIND is sort of a combined recursive readdir/stat. It lets you recursively list a directory, simultaneously gathering any properties of interest, in a single round trip. Properties are identified by a namespaced XML element name, so there's a simple extension mechanism for adding new ones.
The other http extensions in DAV are simpler than PROPFIND and add the ability to create directories and modify properties. There's also an optional file locking protocol.
A vfs library based on this would have core operations of GET/PUT entire file, and PROPFIND to list directories. On top of the standard DAV properties, an icon property would be an obvious addition, and also properties for the UNIX-specific stat() information. Backends would return only properties that made sense for that backend.
VFS backends would be MUCH easier to write if they only had to support GET, PUT, and PROPFIND. They would also be much easier to write if they could provide display name and icon properties instead of making up fake .desktop files.
Operations such as seek, etc. would be optional and implemented only for a local file backend.
Another way to simplify backends is to do path-parsing in the vfs library itself instead of in the backend, I did this for the Mugshot DAV implementation, here is the API for (read-only) backends. Every time I've implemented path parsing (gconf, dbus, Mugshot DAV, probably elsewhere) I've found it hard to get right and tedious, so it would be nice to remove this burden from backends. The only trick with a node-based backend API is to be sure there's a getChild() in addition to getChildren() to avoid gratuitous directory listing / node creation just to resolve a path.
A possible incremental approach to replacing gnome-vfs on the DAV model could initially have a very small library (with just the PUT, GET, PROPFIND operations) that defined the backend API. To start, there's a gnome-vfs backend that calls this library. gnome-vfs continues to handle the volume manager and stuff like that. But backends could immediately be written on the DAV model, and gnome-vfs backends could be incrementally moved to it.
It might be interesting to map even more literally to DAV and have requests to backends look like http requests, with a method and headers. This would make the backend API extensible over time by adding new methods. Adding new file properties is probably more common, but new methods are useful for e.g. adding a seek operation that only works on local files, or whatever.
The value of DAV here isn't that it's a standard (we're talking about a C API that looks like the DAV protocol, not an implementation of the protocol itself). The value is rather that it is roughly correct (few operations, designed to be asynchronous, extensible), and by using an existing model one avoids a lot of design decisions and discussion. Designing a new VFS API is really the hard part, so if that can just be punted to DAV then (assuming it works) it could save a lot of time and energy.
A side benefit is that it's easy to interoperate with remote DAV shares, either exporting a vfs share as DAV or mounting a DAV share with the vfs, and there's no loss of information or semantic mismatch when doing this.
Coded most of a file sharing feature for Nautilus over the holiday weekend, reposting here so it will show on Planet GNOME.
BTW, AbiWord Collaboration looks awesome. Once the site launches I'd like to investigate how it can be Mugshot-integrated so I can get a stacker block when someone I know starts a public document.
