Hiding internal DBUS use inside a library

[Lennart Poettering]

On Fri, 26.08.05 00:05, Colin Walters (walters at verbum.org) wrote:

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

Ok, we implemented that already.

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

Yes, the DBUS API is intended to be stable. It's perfectly OK to use
it directly from any language. In fact the avahi distribution contains
some utilities using the python-dbus to access avahi stuff.

The C wrapper as definied in libavahi-client just makes many things
easier, and resembles the libavahi-core API so that switching between
the two APIs is simplified.

Lennart

-- 
Lennart Poettering; lennart [at] poettering [dot] de
ICQ# 11060553; GPG 0x1A015CC4; http://0pointer.de/lennart/