A common VFS and a Common conf-system [Part II]
prefect_ at gmx.net
Wed Mar 9 02:51:17 EET 2005
On Tuesday 08 March 2005 23:11, gtg990h at mail.gatech.edu wrote:
[snipping large parts of the mail because your premise, which appears only
at the end of the mail, is wrong (IMO)]
> > No, file handling will be the same. Modern apps should prefer the far
> > more expressive and easy to use D-VFS API (POSIX really does suck in
> > many different ways) and legacy apps would need a mounted file system.
> No, it wouldn't. When using "modern" apps, users would have to use
> protocol://file URIs, while using "legacy" apps would use something like
> /mnt/protocol/file paths. Not to mention that users would have to deal
> mounting FUSE shares themselves, etc. What D-VFS should do on
> is to provide an intelligent mechanism for handling the mounting, and let
> mechanisms take care of the rest. As a fallback, it could offer it's own
> mechanisms for those OSs that don't have their own.
A large part of D-VFS will be implementing/bringing together implementations
of remote protocols - in fact, that's its original motivation. What would
you prefer: NxM clients, where N is the number of protocols and M the
number of OSs, or just N clients for D-VFS? I'd take the latter any day,
Besides, the namespace confusion can be eased by providing conversion
functions in the D-VFS library.
> Beyond that, I have a bad feeling about a project that wants to muck with
> something as basic as the UNIX file API, and then declare every UNIX
> in existance to be "legacy". That's making a decision that has huge
> ramifications on the design of the system as a whole, and is not something
> considered lightly. Is D-VFS just a desktop filesystem API, or is its goal
> replace POSIX for all "modern" apps? You can't hedge and say "it's just
> desktop apps, but since POSIX sucks, everything else should be ported to
I agree with some of your points here. Saying "D-VFS is only for the
desktop" is dangerous because in the end, you'll always have to use CLI
tools with the files that the desktop accesses.
However, the desktop is where a better filesystem is most needed, so the
desktop is obviously where the focus is.
> > No, it's the job of people who care about the bridge. I am not stopping
> > FUSE developers from making a D-VFS handler. I'm not going to do it for
> > them, and I won't compromise the design of D-VFS just to make it a
> > little easier for them. POSIX sucks, the entire *reason* to write D-VFS
> > instead of just porting FUSE to BSD and Solaris and such is to provide a
> > simpler, more expressive, less error prone API than POSIX that has the
> > additional immense benefit of handling remote shares transparently.
> I thought the reason for D-VFS was to have a cross-desktop replacement for
> gnome-vfs and KIO. What is D-VFS exactly? Is it an easier to use API?
> that can be done on top of native APIs, ala efsd. Is it a remote
> layer? Because that can (and has) be done in the context of native APIs.
> are orthogonal, and the weakness of D-VFS as a concept is that it
> ties the two together.
That's your broken premise. The native API *doesn't* offer enough for D-VFS.
Even if all the problems related to password prompts were dealt with, how
would you e.g. deal with mimetype or cookies sent by an HTTP server?
In a backend<->FUSE<->kernel<->D-VFS scenario, there will be so much
abstraction going on that we will invariably lose information, and whenever
the need arises to extended the D-VFS API with useful functionality in the
future, all those three interfaces might have to be changed instead of just
a single backend<->D-VFS interface.
It's simply unrealistic to expect all operating systems that open-source
desktops run on to adopt a native filesystem API that allows a satisfactory
implementation of D-VFS. It is equally unrealistic to expect all remote
system clients to be well maintained for all operating systems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050309/190dbf86/attachment.pgp
More information about the xdg