a common VFS - a different approach

[Alexander Larsson]

On Mon, 2003-09-22 at 16:55, Owen Taylor wrote:
> Hi Alex,
> 
> I really don't agree with you on this issue. Of course, we shouldn't
> say "we'll write a common VFS replacement, and on January 1, 2005
> replace both gnome-vfs and kio will be replaced with it." 
> 
> But I do think that working on a shared replacement system is a 
> very worthwhile activity.

I'm not against someone working on it. I'm just expressing my doubt that
it will be finished and acceptable as a future replacement for KDE and
Gnome. I'd love to be proven wrong.

> Advantages without switching GNOME and KDE over:
>  
>  - Can be used by applications that don't depend on GNOME and KDE,
>    and either use Qt/GTK+ directly or use their own toolkit
>    (OpenOffice)

Sure, this would be nice.

>  - Provides a sample implementation for specification we do.

Yeah. Sample implementations are good.

> Additional advantages if we switch GNOME and KDE over:
> 
>  - Shared session state, such as passwords and certificates
>    needs shared implementation to work well.
>
>  - 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.

Sure, there are advantages.

> Responding to some of your points in detail:
> 
> > First of all I think there will be "staffing" issues. I don't think the
> > right people from both groups will be availible and motivated to work on
> > a replacement of their already working code. And if the right people
> > don't work on this chances are that the people doing it will redo the
> > mistakes already done. Rewriting is never right if you can't lean on the
> > experience of the first implementation.
> 
> Learning from experience doesn't require all the work to be done by
> the people with the experience; if you get the API right, if you
> get the basic architecture right, that's where experience counts.

Thats true, but designing the basic architecture is a major piece of
work. And the people who know the issues need to get involved in the
design, and the new people need to really look well into existing code,
existing solutions, current problems and requirements from the desktop
projects.

> 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.
> 
> Making a VFS project that isn't intimimately tied in to the internals
> of nautilus or Konqueror has the potential to open things up to
> a broader group of interested people.

Which brings the risk of the resulting design not fitting for Konqueror
and Nautilus.

> > Then there is the implementation issue. Sharing code like this is quite
> > complicated, especially when it comes to libraries as complex as vfs.
> > People will argue forever on what libraries to use/not use, what
> > language to use, etc. Basically, we don't have enough common code
> > infrastructure to allow something like this to be easily written.
> 
> 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.

Yeah. It could be done. In fact I think a design like d-bus would be the
right: a lowlevel library, including backends written in a
G/K-independent fashion with duplicated code for the datatypes and
algorightms needed, and then two highlevel libraries fitting the vfs
into the glib mainloop/object system and the Qt mainloop/QObject.

> > Then there is backwards compatibility. The existing implementations are
> > very heavily used by the current desktops. A switch of vfs would be very
> > close to a full rewrite of nautilus unless the replacement is very
> > similar in api and behaviour. 
> 
> I don't believe this; gnome-vfs has almost perfectly unspecified
> behavior other than when it comes to the local file system.

I'm not worried about the filesystem semantics here, but rather how the
library works on a larger scale. Nautilus relies heavily on the
asynchronous stuff in gnome-vfs which is implemented with a thread-pool
and a priority scheduler with async cancellation and callbacks in the
glib mainloop on the main thread. If the common vfs were to work
differently the asynch machinery inside nautilus might have to change a
whole lot. Konquereror might have different requirements that conflict
with these.

> > I think the same is true of Konquereor.
> 
> 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.

If we start using only some modules from the common vfs and the rest use
our own many of the advantages you list above (such as authentication)
are lost however.

> > we can't really change it that much, and making it a layer over a shared
> > vfs implementation would probably require that vfs to either be so
> > similar to gnome-vfs that there would be problems with a similar KIO
> > layer, or there would be non-ignorable performance issues with it.
> 
> What evidence do you have that there would be significant performance
> issues? The network is the bottleneck in most cases.

The performance matter most for local file access, but Nautilus uses
gnome-vfs for all access, so the vfs better perform well for local
files. For remote shares performance isn't all that important, as long
as its not horribly bad.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's a sword-wielding arachnophobic hairdresser in a wheelchair. She's a 
bloodthirsty cat-loving widow married to the Mob. They fight crime!