Havoc's Blog

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.

(This post was originally found at http://log.ometer.com/2006-09.html#9)