glib bindings vs. libdus
trenn at gmx.net
Tue Jul 26 00:17:30 EST 2005
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.
More information about the dbus