kio_giobridge IO slave
kevin.krammer at gmx.at
Fri Jan 4 10:51:52 GMT 2008
On Thursday 03 January 2008, Vlad Codrea wrote:
> It links to glib and therefore introduces a compile-time dependency on
> glib. This wastes memory because now KDE has two low-level frameworks
> that have redundant functionality: QtCore and Glib.
It is an IO slave, a separate helper process, so this is hardly a problem.
Avoiding unnessesary dependencies for application libraries is one of the
advantages of doing things out-of-process, isn't it?
> 2) File I/O is fundamental to nearly all KDE apps, and for a KDE
> developer to fix or investigate bugs in GIO/GVFS they would have to
> code in C and learn the subtleties of GLib/GIO/GVFS.
Since it is an additional/optional IO slave, it can just be
deactivated/removed if it causes problems and the usual IO slave will be
Only the maintainer of the bridge slave will have to know this other
> 3) This deviates from the way other kdelibs components like Solid have
> dealt with Glib apps, namely to communicate with them via dbus.
Different situation. The IO slave is already out-of-process, communicating
with the application through the usual KIO channels.
> 4) There already are mature and tested KIO slaves to handle all the
> protocols that GVFS handles, with less indirection and room for bugs.
And, as I wrote above, they are still available and the default and one
doesn't have to use the bridge slave. It just adds another option.
That's what we have plugable backends for, don't we?
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel