Fwd: Re: A common VFS and a Common conf-system [Part II]

[Dave Cridland]

On Wed Mar  9 22:46:31 2005, gtg990h at mail.gatech.edu wrote:
> > Using an example:
> > A webbrowser gets an URL like http//host&path/file?query
> > It uses a convenience function to transform it into a system specific path,
> > on
> > Unix likely something like
> > /dvfs/http/host/path/file?query
> > and then use open() to open that "file"
> > The kernel would see that it has dvfs mounted on /dvfs and relay the open to
> > the dvfs "filesystem"., which would pass the request to the D-VFS daemon.
> > The daemon decodes the "filename" into its URL form, creates a socket and
> > returns when its open() returns.
> 
> It would work more like this:
> 
> Web browser gets a URI.
> It calls the equivalent of open() in the D-VFS API, and passes it the URI.
> The D-VFS library sends the open request to the D-VFS daemon.
> The D-VFS daemon checks to see if the parent is already mounted, and if not, has
> the kernel mount it using something like httpfs.
> The D-VFS daemon calls open() on the resulting path, associating the D-VFS
> "file" object with the underlying fd.
> The D-VFS library uses whatever D-BUS protocol gets defined, and the D-VFS
> daemon implements those actions by reading/writing to the fd.
> 
> The nice thing about this approach is that if the user now wants to use a CLI
> app on the file, they can copy & paste the URI into their terminal, and it "Just
> Works".
> 

No, it doesn't.

It might do, just about, with HTTP URLs, which map *fairly* closely into filenames, files, and directories, although far from completely.

It breaks badly with several other schemes, though.

My head hurts immediately trying to understand how parameters to each segment of a path might be handled. I'm at a loss as to how, to give a concrete example, this URL might be handled:

imap://anonymous;AUTH=ANONYMOUS@mail8.andrew.cmu.edu:143/INBOX;UIDVALIDITY=894294713/;uid=15333

(That's a phishing message, BTW. It's both a "file", of type message/rfc822, which is a grossly inefficient way of looking at it, or else a "directory", containing a header, and a multipart/alternative, containing in turn a text/plain and text/html. Good luck modelling that in POSIX. Be glad there's no multipart/related with Content-Location headers.)

The fact that INBOX is different for every user is a minor inconvenience. The fact that UIDVALIDITY might change between sessions is slightly more fustrating. The fact that I could say:

imap://anonymous;AUTH=ANONYMOUS@mail8.andrew.cmu.edu:143/INBOX/

And be quite valid and sensible if I were listing the contents of that mailbox, but yet it's wrong to then expect the "filename":

imap://anonymous;AUTH=ANONYMOUS@mail8.andrew.cmu.edu:143/INBOX/;uid=15333

... to then be sensible, merely because a message with that UID happens to exist - now that's just broken your semantics completely, I think. Having elided the UIDVALIDITY, the UID is no longer useful. And yet the parent URL, as it were, is still valid on its own.

And bear in mind that for some protocols, you can only "store" to a collection/directory, and you won't know the URL you stored to until *after* the store is completed. (Again, IMAP.) Not terribly POSIX. Some URLs are store-only, with no way of retrieving the document afterwards.

I think we could reasonably expect ftp to be able to "Just work" like this, as well as http - as long as that http scheme URL resolved to WebDAV, and we weren't doing anything too weird.

Much more than that, and we're starting to expect too much.

A URL describes a resource, not a file. Don't expect all URLs to behave like POSIX files, and expect things to break if you do. I'm not even considering the basic fact that most schemes don't even describe anything that could resonably be described as a file.

But yet, if I give my image viewer the IMAP URL pointing to that photo someone just sent me, I can clearly expect the image viewer to be capable of using it. Do I care that I can't use "cp" on it?

FWIW, I'd expect that a web browser remains a native HTTP speaker, and an email client remains a native IMAP speaker, etc. D-VFS just happens to provide basic handling to allow non-native speakers to load and save to places other than files - and in many cases, the semantics of loading or saving just don't map at all to POSIX.

One of those locations might be "mailto:gtg990h at mail.gatech.edu". I look forward to seeing how you intend mapping *that* one to a POSIX filesystem. Especially while not calling it a hack.

Having said all this, a WebDAV filesystem at OS level would be great. FTP likewise. Same goes for many others, I'm sure, but not all those which strikes me as reasonable and desirable to have in D-VFS - and I'm not sure that D-VFS should always use OS facilities even when they exist.

Dave.