a common VFS - a different approach

[Owen Taylor]

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.

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)

 - Provides a sample implementation for specification we do.

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.

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.

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.

> 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.

> Then there is the fact that the already existing implementations have
> enourmous investions in code, bugfixing, implementations and integration
> already, and I think dropping this for an unknown unimplemented library
> is quite bad. And since its unknown people won't fully trust it and keep
> working on the old code on the side, the staffing issue will be worse.

As I said at the beginning, I don't think anybody is saying that we
should switch to a new VFS library prior to it existing; but 
and working.

> 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.

So, a scheme where a gnome-vfs interacts directly with the file system
and otherwise wraps xdg-vfs is almost certain to be workable.

> 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.

> Since almost all gnome apps use gnome-vfs

The number of GNOME apps that support gnome-vfs (or even really use
files) is quite small. A gnome-vfs compatible wrapper has to be
retained, of course, but if we had a nice replacement, I don't see
any problem in gradually moving things over.

>  and its a supported API/ABI
> 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.

> Then there is the fact that the vfs of each desktop is used to implement
> things that are part of the unique user interface experience of that
> particular desktop. Things that don't make sense to share with other
> desktops, unless we can also come to an agreement on a much broader view
> of the desktop ui. In the case of gnome we use vfs to implement things
> like start-here:, applications:, preferences:, and in the future we'll
> have things like computer: and network: which have very specific Gnome
> behaviour.

This is a very manageable problem. We can tag VFS backends as specific
to a particular desktop without any diffulty.

> So, I say, lets take a step back and look at the problems. The problem
> for actual users is that they cannot rely on applications to load the
> same files if the apps are not using the same library stacks. Users
> don't expect to be able to access the gnome desktop ui such as
> preferences: from kde, but they do want to be able to load normal
> document files, such as those URIs given when double-clicking on a file
> in the filemanager, URIs from DnD, uris from recent-files, etc.
> 
> A much less intrusive way of solving this, with a much higher chance of
> adoption and ultimate success is sitting down and specifying the details
> of "VFS URIs", and then making sure that all vfs implementations use
> this common spec. This involves questions about encoding, escaping,
> hostnames in file: uris, common ssh: uri-spec, uri-chaining, etc. Such a
> specification isn't only good for the cross-desktop problems, having
> rigid specifications for such a visible thing as a URI is good for the
> projects themselves too.

Specification is of course, very much a worthwhile activity, and should
start as soon as possible and be as extensible as possible. But
I don't see it as the final answer. It doesn't resolve shared-state
issues, it doesn't allow easy extension by 3rd parties, and it leaves
duplicated effort in an area that is hard enough to get right once.

Regards,
					Owen