[PATCH] Multi-Protocol IO-Slave

Jeff Mitchell kde-dev at emailgoeshere.com
Sun Jan 13 15:17:25 GMT 2008

On Sunday 13 January 2008, nf2 wrote:
> Apart from the desktop/toolkit independence (just GLib and D-Bus) and
> that one VFS is always better than two (For 3rd party applications the
> situation was like the donkey stuck between two haystacks, they avoided
> to choose KIO or Gnome-VFS - which sucks) - yes - i think GIO/GVFS is
> better than KIO and you will want that stuff.

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+ 

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?

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?

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.


More information about the kde-core-devel mailing list