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

[Sean Middleditch]

On Tue, 2005-03-08 at 12:34 -0500, gtg990h at mail.gatech.edu wrote:
> > On Tue, 2005-03-08 at 11:37 -0500, gtg990h at mail.gatech.edu wrote:
> > > > They can patch GCC if they don't like any of those solutions.  Nothing
> > > > about D-VFS will make it impossible for non-desktop apps to use.  It's
> > > > just not something that a whole ton of time is being devoted to.
> > >
> > > That's not a very good answer. Like it or not, something like an IDE is a
> > > legitimate use-case here. Or something like a MySQL front-end, or a number
> > of
> >
> > It's the only answer feasible.  What other answer is there?  There's no
> > other possible solution except FUSE, which is Linux-only, which means
> > that it is completely unsuitable for our purposes.  If an application
> > wants to use D-VFS, nothing stops it from doing so except apathy or
> > ignorance.
> 
> Apathy, ignorance, and inertia. Don't underestimate the power of the triumvirate
> However, saying to the user "sorry the interface sucks, but the gcc folks are
> ignorant" is not constructive.

I never said they were.

> 
> With regards to solutions, one be to seperate D-VFS into a front-end and a
> backend. Design the frontend so it can be implemented on a purely POSIX API.

So you're arguing now for what is already written in the wiki, what I've
already stated several times about making D-VFS usable as a FUSE
backend, etc?

> This will have to be true anyway, if you want to support proper D-VFS semantics
> for the file:// protocol. Then, make a back-end that exposes a POSIX API to
> sshfs, etc, that would work on BSD, Solaris, etc. The back-end's POSIX can be
> real sloppy, as someone mentioned earlier, because the only thing that will ever
> use it would be the front-end. With that in place, it would be moderately easy
> to run the front-end on top of FUSE or something like Darwin's in-kernel
> file-access mechanism (or Windows's!).

Right.

> 
> Yes, this means that file-handling will be different on BSD, etc, than on Linux
> or Darwin or Windows. That's okay, because its better than file-handling being
> different between apps on the same system.

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.
A BSD version of FUSE would, I assume, work much like a normal BSD
mount.

> 
> > > other applications in which 'desktop' and 'CLI' apps have to work together.
> > > We're talking about UNIX desktops here --- CLI apps won't just go away, and
> > its
> > > useful to the user to allow them to work together.
> >
> > Then they will need to be ported just like the desktop apps.  I'm rather
> > looking forward to getting some CLI apps using D-VFS, such as Vim.
> 
> The apps the user wants are never going to all be ported. The onus is on D-VFS
> to make sure it works with the POSIX apps, not the other way around.

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.

> 
> > FreeDesktop isn't about just Linux, and neither is D-VFS.  End of story.
> > If you don't like that, there is nothing I can do about it.
> 
> FreeDesktop is about creating the infrastructure to allow writing good desktop
> apps. To the extent that writing good desktop apps isn't always possible in a
> cross-platform manner, it becomes a conflict in the principles of
> freedesktop.org. I would argue that it's not wrong to resolve quality vs
> portability issues in favor of quality, as long as a fallback is available for
> other platforms.

Fortunately, I don't think the FUSE approach is anywhere near quality,
so I can happily achieve both.  ;-)

When and if you can get a new set of syscalls into the kernel, a new set
of local file systems that support enhanced meta data processing, and an
API in libc that makes using those facilities and remote shares easy and
transparent, then I will agree that D-VFS is the worse design.  So long
as you constrain yourself to POSIX, you will always be less than ideal,
and I'm not going to waste time design a library that essentially does
nothing useful except add an alternative to the same capabilities POSIX
offers.  You can already write sshfs, davfs, smbfs, and other fs drivers
straight for any kernel - the purpose of D-VFS is to go above and beyond
the limitations that those solutions would enforce.
> 
-- 
Sean Middleditch <elanthis at awesomeplay.com>