Common VFS: GKIO experiment

[nf]

Hi!

On Wed, 2004-12-08 at 03:45, Sean Middleditch wrote:
> > 
> 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.

But i am sure all those Gnome-VFS problems will be fixed soon anyway.
The pressure it very high on that.

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

I think the event-loop gap has to be closed anyway to be able to write
common libraries more easily in the future. And i have already proved
that this is solvable by running the whole KDE on top of glib main loop.

>  Now, actually getting the changes
> upstream, and thus having a chance in hell of any users ever benefiting
> from the work, is another story.

Yes - that's definitely another story. too early to discuss that. 

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

I think what rules out the "two library" approach is sessions. Consider
a ftp-server, which only permits one session per user. Thus when one VFS
connects to this server, the other will be locked out. Probably there
are lots of situations where you can only have a single session.

The other thing is just efficiency. Having to write code which does
exactly the same thing in a duplicate manner - every time you add a new
protocol - is not a clean solution. Also there will be lots of troubles
if the list of available protocols is not in sync 1:1 for the two VFS
libraries.


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

Of course those pseudo protocols need to be on a kind of "blacklist" for
GKIO.

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

My favorite example: You open a SMB or FTP location with nautilus. You
type in your username and password to authenticate and browse the share.
Then you fire up K3B to burn a file from this share to a cd. You don't
want to authenticate again. You want a single session in between your
desktop and the network server, regardless which applications you use.

Cheers
Norbert