Common VFS: GKIO experiment

[Sean Middleditch]

On Wed, 2004-12-08 at 02:57 +0100, nf wrote:

> I think it's the talking about beautiful long term solutions which
> creates this deadlock situation. The fact is that nobody wants to write
> a third VFS at the moment (or do you know of someone?). As a "user" i

It's on my "list" with all the other projects I've half started and
haven't been properly motivated to carry through on.  ~_^

The architecture really isn't that complex.  Getting the core framework
in place, in all honesty, probably wouldn't be more than a week or two
of work, and that's assuming you can't work full-time on it.  Getting
the actual VFS plugins shouldn't be hard since gnome-vfs, kio-slaves,
fuse, and other VFS systems all have code you can re-use.

Really, the only hard part is getting the API right.  If I'm going to
write a new VFS, I want the get the API as good as it can be.
Developers generally couldn't care less about the low-level system
details like using the normal UNIX/ANSI interface requires - they have
high-level operations they want to perform, and the API should handle
those transparently and independently of how much work the backend
requires to do it.  Getting the error handling, main loop integration,
and so on *working* is easy enough, but getting it *right* is a tad bit
more difficult.  Which is one of the things gnome-vfs developers have
noticed, from the discussions I've followed on it.  ;-)

> want a working desktop tomorrow - and not in 10 years time. (Re)use and
> improve the code that exists - dreaming won't help.

> What's so wrong and buggy about Gnome-VFS in detail(!!!) that can not or

The fact that at GNOME 2.8, SMB browsing (one of the most important
protocols) *still* doesn't work reliably for many users?  The fact that
most GNOME apps, even after 2 years of the 2.x series, still do not
fully (if at all) support GNOME's own VFS API?  Even the basic text-
editor GNOME ships with refuses to write to gnome-vfs shares.  I'm an
avid GNOME user, I generally don't touch Qt or KDE, but I do envy KIO -
the few times I've used it, it's worked flawlessly.

> will not get fixed? Which functionality does KIO offer via it's API that
> Gnome-VFS doesn't have? Where are the technical obstacles which would
> prevent GKIO from working? That's what i am interested in.

The disparate event loops are number one, although that's certainly
solvable.  Other than that, there probably isn't a whole of technical
reasons why it wouldn't work.  Now, actually getting the changes
upstream, and thus having a chance in hell of any users ever benefiting
from the work, is another story.

One then also has to ask, what gain will gnome-vfs + KIO actually give
you?  KIO can access everything gnome-vfs can, and then a number of
things it cannot.  Most of the differences you run into are *semantic*
differences, and you *do not* need to marry two very different libraries
to fix those - you need to define what semantics both libraries should
use and get them both to do so.  That will fix the mixing of URLs -
mixing libraries isn't all that likely to do so.  Most of the stuff
gnome-vfs does that KIO does not are the magic GNOME bastardized evil
fake protocols like applications:/// and so on, which really have no
business being distinct URIs, but are an internal gnome-vfs thing and
something that is, honestly, rather private to GNOME anyhow.  Apps
shouldn't even use them, just the core desktop stuff.

If you want to go for your experiment, but all means, please do.
Perhaps first, however, you should more clearly describe the *exact* (in
detail!!! as you put it) problems you are trying to solve, with
examples, and perhaps see if there is an easier, cleaner, saner way to
solve those problems.

> 
> Cheers,
> 
> Norbert
> 
> 
>  
> 
> 
> 
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg
>