Update on DeviceKit

[Marcel Holtmann]

Hi David,

> > > This is a simple system service that a) can enumerate devices; b) emits
> > > signals when devices are added removed; c) provides a way to merge
> > > device information / quirks onto devices. And that's it. A device is
> > > identified by a) the native OS-specific path (on Linux a sysfs path); b)
> > > an optional UNIX device file; and c) key/value pairs describing the
> > > device. It's a very simple service, a bit like what HAL is today without
> > > all the probers/callouts
> > 
> > do we really have to use dbus-glib and GObject inside this daemon. I
> > would prefer if we can keep the dependencies to GLib and D-Bus low-level
> > and then use something like libgdbus as D-Bus helper library (or even
> > embed it).
> 
> So I did look at libgdbus but decided not to use it as, AFAICT, it
> forces me to do marshaling by hand; is that still the case? FWIW, it's
> not like I think dbus-glib is the best thing since sliced bread but it
> does get the job done. Ideally, I'd like to use a GInterface based
> framework using DValue. If something like that appears I'd be happy to
> move the code over, shouldn't be a big change.

it is true that you have to do most of the marshaling by yourself, but
actually it is limited to retrieving the arguments from a D-Bus message
and creating your return/reply messages. In fact for the use cases of
DeviceKit it is no overhead (as far as I can tell at the moment). The
advantage would be to not require the GObject part of GLib. I think that
having a requirement on GObject for a system daemon that deals that
closely with hardware and is expected to be present everywhere (and this
includes tiny embedded devices) is not good.

> > 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, like most other people, prefer to use languages/frameworks that are
> object oriented for a lot of reasons. And I'd hate to reinvent the wheel
> doing a lame object model myself like with PolicyKit (granted, this was
> done for other reasons). And GObject already does this very nicely
> though, admittedly, the learning curve is pretty steep (as compared to
> e.g. C++). And, frankly, IIRC a lot upcoming embedded devices using
> Linux are already using GObject elsewhere in the stack.

I fully disagree here. The GObject requirement for such a low-level
daemon like DeviceKit is wrong. It is simply too much and it gives you
no real advantage (besides the little marshaling). I also don't follow
your point why an object oriented model is at all useful in this kind of
daemon. My understanding was that DeviceKit should bit small and simple
and thus I can't see your point. If you need GObject, then the design
might be already too complex.

That some embedded devices carry around GObject or dbus-glib already
doesn't seem like a good base to built this requirement on. Especially
when the UI system is something like Enlightment or Qt, then having
GObject enabled GLib makes no sense. And you would only push this into
because of DeviceKit. This doesn't look right to me. The core part of
GLib has been widely accepted and can be expected to be available on an
embedded system (if not they can use eglib), but the GObject part should
not be a requirement.

I like the idea behind DeviceKit and I like to see it running on every
system. However if we keep pushing desktop requirements to the embedded
world, we really will loose that goal.

Regards

Marcel