a common VFS - a different approach

[Alexander Larsson]

I have some doubts that we will be able to come up with a decent common
vfs codebase that is acceptable by all desktop projects, and that will
actually be used. This mail details some of the reasons I think such an
implementation isn't feasible, and then end with a different proposal
that I think will be "good enough" which has a much higher chance of
success.

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.

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.

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.

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 think the same is true of Konquereor.
Since almost all gnome apps use gnome-vfs, 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.

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.

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.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 Alexander Larsson                                            Red Hat, Inc 
                   alexl at redhat.com    alla at lysator.liu.se 
He's an immortal flyboy master criminal who dotes on his loving old ma. She's 
a vivacious tomboy nun with the soul of a mighty warrior. They fight crime!