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

[Nicolai Haehnle]

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 
with
> mounting FUSE shares themselves, etc. What D-VFS should do on 
Linux/Windows/OS X
> is to provide an intelligent mechanism for handling the mounting, and let 
native
> 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, 
thank you.

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 
application
> 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 
to be
> considered lightly. Is D-VFS just a desktop filesystem API, or is its goal 
to
> replace POSIX for all "modern" apps? You can't hedge and say "it's just 
for
> desktop apps, but since POSIX sucks, everything else should be ported to 
it
> too".

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? 
Because
> that can be done on top of native APIs, ala efsd. Is it a remote 
filesystem
> layer? Because that can (and has) be done in the context of native APIs. 
The two
> are orthogonal, and the weakness of D-VFS as a concept is that it 
unnecessarily
> 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.

cu,
Nicolai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050309/190dbf86/attachment.pgp