[PATCH] Multi-Protocol IO-Slave

nf2 nf2 at scheinwelt.at
Sun Jan 13 14:18:03 GMT 2008


Aaron J. Seigo wrote:
> On Saturday 12 January 2008, Albert Astals Cid wrote:
>   
>> This is my first and last comment to this thread but i really don't see why
>> we want that in KDE, it seems to me that we already support everything
>> gio/gvfs does and probably better since our KIOs have been much more tested
>> that their new gio/gvfs code, so i don't see the point in this unless it's
>>     
>
> i don't think the benefits have really been communicated at all, no.
>   
Seems like the benefits really need better advertising :-)

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.

The most important thing about GIO/GVFS is that introduces a "stateful" 
design - very similar to UNIX mounts. You "mount" a network server, type 
your password and all applications can work with this share until you 
unmount it. Unlike KIO and Gnome-VFS the connection-state is user 
manageable (Mount/Unmount).  Mounted network resources get listed in all 
file-managers and file-choosers (and perhaps on the desktop) just like 
your CD-Rom or USB-pen-drive.

The mounts live in multi-threaded mount daemons - one per user at server 
mount - applications connect to them via IPC. Cause there is only one 
daemon process for a certain user at server, connection state, connection 
pooling and -sharing is easier to handle. There is no need for a 
password cache. Of course all KDE, Gnome, 3rd party apps in a desktop 
session should use the same mount daemons through the GIO client. You 
don't want to login twice when working with a KDE app and a GTK app on 
the same server. And you don't want to have two instances of 
libsmbclient talking to the same server. Of course having the same list 
of network drives in all file-managers and -choosers is very important 
for a consistency and therefore usability. Also, sharing connections 
means you won't hit the "number of connection" limits, some servers have 
(Which i already experienced, when using KDE apps along with a Gnome-VFS 
apps on the same FTP server).

There are other nice features like the quite flexible API for directory 
listings and dir-entry properties, but they are less important i believe.

Norbert
















More information about the kde-core-devel mailing list