C-API

[John (J5) Palmieri]

On Thu, 2006-10-12 at 16:28 +0100, Peter Clifton wrote: 
> Hi,
> 
> I'm in the situation where I need to provide dbus support in an
> application, where the GUI front end of the application is pluggable,
> and can either be GTK, Lesstif, or other. Each has its own mainloop and
> way of doing things.
> 
> I've currently got GTK only support working. The code is very simple,
> there are only two methods.
> 
> Is there a standard solution for coding a more generic implementation
> using the libdbus C API on its own?
> 
> All the pluggable GUIs in the application can be requested to provide
> timer callbacks, and file descriptor monitoring callbacks.
> 
> What would be really nice would be an API, slightly higher level than
> the RAW C API, but providing asynchronous functions via a function
> pointer based callback system. (Perhaps marshallers or similar would
> still be needed).
> 
> Setting up this API would require the app to register whatever
> file-descriptor and timer callbacks that the dbus part asks it to, and
> the rest should be simple. ^TM
> 
> I was wondering if we could use a code generator of sorts to provide the
> glue, much as dbus-binding-tool does for the glib stuff.
> 
> Where do the DBUS people stand on this type of problem... I need a main
> loop independent DBUS library, which is ideally a little friendlier to
> use than raw libdbus.

A couple of ways you can go about this.  You can write your own mainloop
integration for each mainloop you care about (hard but most efficient
use of resources).  You could simply call
dbus_connection_read_write_and_dispatch with a 0 timeout in a source
(most likely the least efficient but easy to implement) or you could
compromise and call dbus_connection_read_write_and_dispatch from a
thread.

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