kio_giobridge IO slave

[Kevin Krammer]

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 
used.
Only the maintainer of the bridge slave will have to know this other 
libraries.

> 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?

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080104/7bc70933/attachment.sig>