[PATCH] Multi-Protocol IO-Slave
nf2 at scheinwelt.at
Sun Jan 13 17:06:26 GMT 2008
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+
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.
More information about the kde-core-devel