kio_giobridge IO slave

[Vlad Codrea]

--- Kevin Krammer <kevin.krammer at gmx.at> wrote:
> 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?

If a distro or user chooses to compile QtCore without linking to Glib,
it becomes impossible to compile or run the kio_giobridge IO slave.
That's OK because the existing KIO slaves already do everything that
kio_giobridge does.

Including kio_giobridge in kdelibs means that kdelibs will *not* be
compilable on a pure (Glib-less) QtCore, effectively mandating linking
to Glib by *all* Qt and KDE applications.
 
> > 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.

Not really, because once distros are forced to link QtCore to Glib,
then all Qt and KDE apps will have to link to Glib and run on Glib's
non-native and slow event loop. 

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

Options are great, but let's not mandate the kio_giobridge option and
its dangerous Glib baggage by placing it in kdelibs. I would agree
with Kevin Ottens that kio_giobridge should reside where it is
available to but not forced upon users, like extragear.

Best Regards,
Vlad


      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs