a common VFS - a different approach
otaylor at redhat.com
Mon Sep 22 17:55:07 EEST 2003
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
- 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
> 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
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.
More information about the xdg