Update on DeviceKit

[Marcel Holtmann]

Hi Matthias,

> >  I personally think that GObject should only be used in UI applications
> >  and not within system daemons. Especially when I look into the embedded
> >  world, it would make sense to keep the dependencies really small and
> >  give people a chance to use something like Embedded-GLib (eglib) if they
> >  have limited resources, but still wanna use standard technology like
> >  D-Bus and HAL/DeviceKit for most tasks and not invent everything over
> >  and over again.
> 
> I hope you realize the irony of using 'eglib' an 'not inventing over
> again' in the same paragraph...

the question if the core GLib is good enough or too bloated or not is
for me not a question. For me this is more about having a common API
that takes away the pain of dealing with mainloops, timers and so on. If
this is a GLib from gtk.org or the eglib from the Mono or even the eglib
that the Bluez project still carries around is unimportant. There are
various reasons why people started to re-implement the GLib API.
Personally I prefer using the plain GLib, because that has been tested a
lot within the GNOME desktop and Maemo platform, but sometimes a system
really only needs a subset or the license is not right or whatever. I
don't care. The important part is to base it on the GLib API which could
be re-implemented and already has been to fit embedded needs. Not that
the original version is any bad. I think it is perfectly fine, but some
embedded guys have different requirements for size etc. Dragging GObject
into this picture makes it complex and bloated. I think GObject is a
good concept and works out fine for UI applications, but it is not a fit
for system daemons. Especially if the UI that you wanna put on top is
using a total different object system. For example if I use Qt or
Enlightment or something, why do I have to install GObject?

Regards

Marcel