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

[Dave Cridland]

On Thu Mar 10 02:22:30 2005, gtg990h at mail.gatech.edu wrote:
> Quoting Dave Cridland <dave at cridland.net>:
> > 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.
> 
> There is no reason to expect more than what can be represented via POSIX +
> xattrs. I think you can do quite a lot with that combo, but you clearly can't do
> everything. That's okay, because you don't have to represent everything as POSIX
> (or Win32, or whatever the host OS is). If the user cannot be reasonably
> expected to want to use CLI tools on files behind a given protocol, then the
> D-VFS daemon can just implement that protocol itself. The nice thing is that the
> protocols on which the user might want to use existing tools are correlated with
> those that lend themselves to being represented using existing file APIs.
> 

Right... So what you're saying is *not*:

"I want to ditch the entire concept of a userland VFS system, because the kernel could do these things."

But:

"I want to be able to access some D-VFS features via a POSIX API, through traditional mounts."

Everything else you say is implementation detail, precisely the same kind of erroneous argument (at this stage) as you're accusing Sean of. It doesn't matter, in principle, whether D-VFS mounts filesystems in the kernel, or whether the POSIX semantics rely on forwarding stuff via FUSE and similar to D-VFS.

FWIW, I agree that if we can sanely shift, for sake of example, FTP access into kernels, then we should. But that's not always possible - some FTP servers are simply sufficiently esoteric that they make this kind of thing impossible [They're still standards compliant, just weird]. I'm deeply unconvinced that HTTP can work this way too, without WebDAV, and I deeply worry that we end up with the horrible mess of, instead of a POSIX API, an API which has been bent and broken to vaguely smell like POSIX. It's bad enough with NFS and Samba, and they're *good* examples.

> 
> > 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?
> 
> Exactly. But similarly, if somebody links me to a TeX file on a ftp drive, I
> *do* expect to be able to run pdftex on it.
> 

Expect away. To make this work efficiently and sanely, you're expecting the kernel to handle a slew of internet drafts and heuristic parsing. I think this is sufficiently nasty to warrant handling FTP in userspace anyway.

> I should not that I'm not saying that "D-VFS shouldn't use URIs", rather that
> "URIs shouldn't be mandatory". This seems obvious, because you still want to
> support names of the form "/home/me/document.txt" for file://, but that needn't
> be a special case as it is in KIO and gnome-vfs. Namespaces only need to be
> unified for things that the user considers to be files. That means it would be
> nice to extend native pathnames to filesystems (ssh, ftp, etc), that the user
> could reasonably be expected to consider as containing "files".

Okay... Let me summarize:

You want an API that, when a process requests of D-VFS access to some file, D-VFS can essentially hand back a local filename - a sort of redirection. This would, presumably, always happen in the case of file scheme URIs referencing the local filesystem, but might also happen for WebDAV enabled "http" ones. Is that about right?

Dave.