Re: impending gdbus merge

[Matthias Clasen <matthias clasen gmail com>]

On Sun, May 9, 2010 at 4:42 AM, Daniel Macks <dmacks netspace org> wrote:
> On Thu, 2010-05-06 at 14:06 -0400, Matthias Clasen wrote:
>>
>> I thought I should let everybody know that we are getting very close
>> to merging gdbus into GLib. David has created a gdbus-merge branch
>> where we'll stage things before the final merge to master. So, if you
>> haven't payed attention to gdbus yet, or haven't looked at it in a
>> while, gdbus-merge is the branch to watch in the next few days.
>
> I'm a downstream packager, figured this is a good time to ask some
> questions about gdbus relates to existing dbus daemon and library
> packages based on freedesktop sources.
>
> Seems like gio implements the dbus protocol in gio directly and does
> not sit on top of the actual dbus libs (except 'make check' self-test)
> but is compatible? I don't see a daemon in glib though, so do I still
> need the dbus daemon itself and associated programs from the
> freedesktop dbus distro (a libgio-shlibs:Depends:dbus-daemon
> dependency for example)? And therefore everything shares the same
> system and session busses (and clients can talk to each other on the
> same bus regardless of which client lib they use)?

gdbus reimplements the client-side entirely itself and do not rely on
libdus, indeed. There's multiple reasons for that:

- no use for the OOM handling that libdbus needs because it is also
used in the daemon

- libdbus brings its own transport layer, but gdbus sits inside GIO,
so it would be silly to not use GIO for the transport layer

- libdbus has issues with multithreading that are very hard to avoid
unless you avoid libdbus altogether

That being said, this is all still dbus at the protocol level - the
use of libdbus in the testsuite is there to verify various aspects of
compatibility. It would be pointless to include our own daemon
implementation.

Its worth pointing out that there are already multiple alternative
implementations of the dbus clientside, we are not the first to shun
libdbus...

> Should I consider gbdus-tool a developer item (in libgio-dev, along
> with headers and other compile-time files) or a separate end-user item
> (useful for systems at runtime)?

Hard to answer that. Currently, it is a functional equivalent of
dbus-send. Do you consider that a end-user tool ? It will probably
pick up monitoring
functionality at some point, as well.


Matthias