glib bindings vs. libdus

[Thomas Renninger]

Hi,

I added DBus communication to an app which runs as
a daemon, hanging on a select as "mainloop".

I tried to avoid using glib bindings because:

    - I need file descriptors for the select loop to listen on.
    - I considered changing the select loop into a glib mainloop,
      however this seemed to me rather complicated.
    - As this is a daemon I do not want to link against a bunch of
      (heavy weight - e.g. like QT) extra libraries.

After a lot of work I got it running (beside some little edges -
e.g. I only use one fd/watch at the moment, I think for multiple
connections I need handling of multiple watches/fds? ...)

Now I read that hal will also use the glib bindings, soon.
Collin Walter/David Zeuthen:
__________________________________________________________________
>Introspection support is something apps written with the GLib bindings
>> get for free, hopefully HAL will use them soon.

Yea, I really want this soon but I want the GLib bindings to settle in
before doing it so you need to tell me when these bindings stable :-)
__________________________________________________________________

So if hal is doing it, the last argument above seems not to be valid.

Could someone please comment on advantages/disadvantages/musts for
using the glib bindings vs. the low level dbus functions?

Assuming I'd implement a glib mainloop, is this how it would look like?:

     - Initialising DBus stuff and pass over mainloop.
     - In mainloop I set up my file descriptors I like to watch and
       wait on a select.
     - DBus queries are somehow handled in the background (threaded, I think not?)
       and I get invoked through callbacks while my mainloop still waits for fds to get readable/writable
       on the select.


Thanks,

   Thomas