Fwd: Re: Fwd: Re: A common VFS and a Common conf-system [Part II]
dave at cridland.net
Fri Mar 11 13:44:50 EET 2005
On Thu Mar 10 22:14:08 2005, gtg990h at mail.gatech.edu wrote:
> Quoting Dave Cridland <dave at cridland.net>:
> > 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.
> Only theoretically. To the extent that the spec mandates things just not
> possible on top of POSIX, the two cases become different. That said, I've
> already told Sean that it's not really useful to harp on the specifics until we
> see the real barriers POSIX puts up as D-VFS is implemented.
> hat makes them any more unusual to handle in the kernel than, say, NTFS.
Right, okay, I think I follow. However, I think D-VFS may well need to provide functionality or semantics which POSIX cannot, at times.
I agree with your implication that my statement above should be true - that is, it should make no practical difference which "direction" the POSIX functionality is implemented. I am, however, assuming that for most cases, the D-VFS API would be superior for desktop application usage.
> > 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?
> Or CIFS ones on SSH ones, or any of a number of others already supported by
> various kernels.
Yes, I know there's more - no reason not to hand back an arbitrary filename pointing to a local file in cache, if the resource has been previously fetched and is up to date.
Do we allow the application to use D-VFS anyway if it wants? I see two use cases for this:
1) An application knows there is functionality or metadata available through D-VFS not available through POSIX for the resource.
2) An application "prefers" the D-VFS interface for all accesses, possibly because it is restricted to merely a "Send To..." style of functionality expecting a URL.
More information about the xdg