Hiding internal DBUS use inside a library

[Colin Walters]

On Fri, 2005-08-26 at 00:56 +0200, Lennart Poettering wrote:

> The user of our library fills a vtable with his own implementations of
> functions for creating and modifying time or IO event sources. We use
> those functions internally for all housekeeping we need to do and - in
> the case of libavahi-client - to drive an internaly used
> DBusConnection. For that DBusConnection we set the timeut/watch
> functions to some glue code with translates them to our event loop
> abstraction layer. The abstraction layer is actually very thin, since
> it resambles the DBUS event loop abstraction a bit.

Urgh.  I guess given your goals Havoc's suggestion of using
dbus_connection_open_private is right.

This seems like a lot of pain though, both for users of your library who
want to integrate it with their apps using a mainloop like GLib, and
also for you as developers.  I'm not sure I see why you have such a
strong goal of avoiding a D-BUS dependency.  But I don't understand the
compatibility issues between libavahi-client and libavahi-core though...

I hope at some point though that you declare the Avahi D-BUS interface
stable, and support clients using it directly through bindings such as
Python or GLib.  The protocol looks simple enough.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.freedesktop.org/archives/dbus/attachments/20050826/26d64ccc/attachment.pgp