a common VFS - a different approach

[Alexander Larsson]

On Mon, 2003-09-22 at 22:44, Ken Deeter wrote:

 
> >  - We can actually have real modularity and have that work
> >    for all applications on the system.
> > 
> >  - Interoperability *will* be better with shared implementation.
> > 
> >  - In the end, duplicated effort will be reduced.
> > 
> > Responding to some of your points in detail:
> > 
> 
> > I think there is plenty of evidence that people consider VFS sorts
> > of things to be interesting things to work on; look at all the
> > projects that have been mentioned here recently.
> >
> 
> I agree. Especially with a high profile group like freedesktop behind a
> proposal, i think people who have all sorts of ideas on userland fs's would
> join in, because it has a much higher percentage of acceptance.
> 
> I think most people who work on these vfs things always think to some extent
> "if only all applications could use my API, then look what i could do".
> This is a real opportunity for that to happen.

Remember that the freedesktop group is just an organization that lets
people work together. Its not a coherent group that can solidly "stand
behind a proposal". Its a place where you can propose ideas, and a other
people can shot it down, agree, disagree etc. The only way to make it a
real (as in working, implemented) standard is to make it good enough,
and meets the requirements so that the major players take it up and use
it in their desktops.
 
> > I think you exagerate. Of course, this issue does make implementation
> > harder, but certainly there are plenty of examples of successful 
> > "plain C" libraries that are shared; fontconfig, libjpeg, D-BUS seems
> > to be working out well.
> >
> 
> I think d-bus could be an enabling factor here. It really lets you not
> worry about things like ABI compatibility (in the linking sense), which
> lets you be much more flexible. All you have to maintain is the message
> passing protocal compatibility, which is like saying, you have to comply
> with the HTTP spec. Think about all the different HTTP implementations
> out there. 

I'm not at all sure dbus is a good solution for this. DBus was mostly
designed for a higher level of communication, enabling scriptability and
communication between system/desktop. It was really not designed for the
small-scale, high-bandwidth, tight coupling kinds of APIs i see in a
vfs. I think dbus is really cool and useful, but any technology has its
place, and you have to respect that when using it.

The DBus API and semantics are in flux. The code is new and not
finished. We don't know anything about its performance characteristics.
It's not deployed yet. We don't know what problems and weaknesses it
has. We don't know how it will be used, and to what degree it will be
adopted.

I'm just worried about dbus usage as a form of "design by latest hype"
instead of proper determination of requirements leading to a design.
I've just seen this sort use-the-latest-thing designs end up horrible
broken designs to many times before. 

> > Konqueror is going to likely be more of a challenge since it apparently
> > interacts quite deeply with the SSL guts of the kio, but still,
> > the issue is not realy file:// and http://, but all the other possible
> > VFS backends out.
> >
> 
> I think there will be always cases where the app wants to get into the guts,
> and so there should be a mechanism by which this is made possible.

Personally I think we should avoid this. It just makes things overly
complicated and hard to use. A VFS should be about file access, and a
webbrowser needs much more than that. The webbrowser should use a
separate library. We just can't make a common vfs that is good enough
for any webbrowser to use as the underlying http library. (And thats
what a common design would have to do.)
 
> > This is a very manageable problem. We can tag VFS backends as specific
> > to a particular desktop without any diffulty.
> > 
> 
> I totally agree. Nothing says you 'have to' use a particular backend.

So, we are not in fact talking about a common vfs library, but rather a
vfs implementation separate for each project, and a way to implement
third party modules that can be used by both desktops?

It does seems so if you start talking about picking just the backends
you want.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a suave soccer-playing master criminal moving from town to town, helping 
folk in trouble. She's a strong-willed tempestuous traffic cop prone to fits 
of savage, blood-crazed rage. They fight crime!