[PATCH] Multi-Protocol IO-Slave

[nf2]

Jeff Mitchell wrote:
>
> Some of the things you mentioned sound nice, but apart from the requiring glib 
> thing, I have a few questions:
>
> First, on http://live.gnome.org/GioToDo it says, "There is some parts of gio 
> that should really be in Gtk+ that apps might need. Long term this should go 
> into Gtk+, but for now we might want to put these in a separate desktop 
> library so that apps can start using gio easily before the next Gtk+ 
> release."
>   

That's just GUI stuff in the layer above (like password dialogs). You 
wont need that stuff, because of the "passive" design of GIO/GVFS: It 
will never prompt for passwords, unless you trigger a mount operation. 
In kio_giobridge i use the KIO Slavebase authentication system when 
hitting a not-mounted resource.

> While these classes could be worked around by having KDE implementations, I 
> find it a bit troubling that they want to move some parts of GIO into GTK.  
> Then your dependencies go from glib/dbus to glib/dbus/gtk, at least by 
> default.  What other parts of GIO/GVFS might they at some point decide really 
> belong in GNOME-specific libraries?
>   
None. I think they decided that having the VFS core engine in the 
desktop layer is just wrong (and has always been IMHO).

> >From http://fosswire.com/2007/11/25/goodbye-gnomevfs-hello-giogvfs/ 
>
> "One complaint about GnomeVFS is that mount points cannot be accessed by 
> non-GnomeVFS-aware applications. GVFS uses a FUSE bridge to make these 
> publicly accessible...This FUSE bridge makes it possible for literally any 
> application to use GVFS, even if it is not aware of it."
>
> Perhaps something to consider for KIO in the future?
>   

I played a lot with FUSE recently, working on this project: 
http://www.scheinwelt.at/~norbertf/devel/fusi/ The problem is that it's 
very hard to map certain protocols like FTP into POSIX (because POSIX 
semantics always expect that open(O_RDWR) + seek() works). Also, things 
like cancellation are difficult.

But - if you want a FUSE bridge you don't need to write your own. Just 
use the one that comes with GVFS.

> Personally, I'm all for a single network transparency library (or a single 
> authentication caching library, which would serve the purpose).  I do think 
> it's utterly stupid that the GNOMEs couldn't contribute to KIO, which already 
> has a bazillion working, useful KIOslaves, unless they felt (as they seem to) 
> that GIO/GVFS is better by design.  Still, it does reek a bit of "we just 
> can't allow ourselves to use anything with a K in it" syndrome.
>
>   

The problem is that KIO always had desktop/GUI-toolkit dependencies and 
KDE developers never cared to remove them - so it's your fault, guys. 
Also, having a Qt based client library is less liberal in terms of 
licenses. Of course, rewriting the core of KIO in plain C (or better 
GLib + main-loop + C) should have happened many years ago. But the 
outcome of such a KIO redesign would have been very similar to GIO/GVFS 
anyway. I posted a proposal myself on xdg list many years ago - 
http://www.scheinwelt.at/~norbertf/common-vfs/newdesign.html - the idea 
of a "stateful" VFS with mount daemons is not new.

And please don't try to "just" fix this issue with a shared 
authentication caching service. Having multiple VFS systems is a 
disaster (maintenance and code duplication). You can't introduce new 
protocols without writing everything twice and you always have to make 
sure that the list of installed handlers and their behavior is aligned.

Norbert