glib bindings vs. libdus

[John (J5) Palmieri]

On Mon, 2005-07-25 at 16:17 +0200, Thomas Renninger wrote:
> 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.

Qt is quite different from glib.  glib should not be feared for deamon
development.

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

Hal uses glib already it just never used the bindings because they were
never in a usable shape until now.

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

If at all possible we want to discourage people from using the low level
bindings.  In some cases that is not possible but in most cases once
bindings are done they should be used.  The argument is that in theory
the bindings should be less susceptible to change in the underlying
library. Of course that hasn’t been true in the last few releases. The
bindings also make sure things like introspection are handled correctly.
A lot of D-Bus (like object paths and interfaces) are simply concepts
that are not enforced by the lower level library and can be easy to
misuse. Bindings on the other hand integrate D-Bus into their own
framework, mapping these abstract concepts to concrete rules. 

> Assuming I'd implement a glib mainloop, is this how it would look like?:
> 
>      - Initialising DBus stuff and pass over mainloop.

dbus_connection_setup_with_g_main (DBusConnection *connection,
GMainContext *context)

the context can be NULL which mean use the main context.

>      - In mainloop I set up my file descriptors I like to watch and
>        wait on a select.

You can set watches on IO in glib.

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

It is handled by the mainloop in the same thread.  Are you using the fds
for watching the bus or something else?  The glib mainloop should take
care of handling any D-Bus message.  You don't need to do your own
checking.

-- 
John (J5) Palmieri <johnp at redhat.com>