Announcing availability of libgdbus

Marcel Holtmann marcel at
Thu Apr 17 16:05:08 PDT 2008

Hi Simon,

>>>>> I think all the stakeholders in dbus-glib agree it is fairly
>>>>> fundamentally broken from an API standpoint and doesn't have much
>>>>> of a
>>>>> future.  Any objections to elevating libgbus to more "official"
>>>>> status
>>>>> by having it in the bindings page?
>> Not just that, but the current dbus-glib could be simply renamed to  
>> dbus-gobject
>> that would reflect what it really is. (I know this is not feasible.)
> Once libgdbus has a release and some sort of API/ABI guarantee, I'd be
> quite happy for the bindings page to say something like:
>    = libgdbus - GLib/D-Bus event loop integration and utilities =
>    ... release notes blah blah blah ...
>    = dbus-glib - GObject/D-Bus object model integration =
>    ... release notes blah blah blah ...
> that makes it clear that libgdbus and dbus-glib have different scopes.

sounds good to me. A release is not a problem. but the API/ABI  
guarantee, I am not so sure right now. I like to get feedback about  
the API from others and what they think about it.

> Depending how tightly defined libgdbus' scope is, it might be possible
> for dbus-glib to be implemented in terms of it (i.e. libgdbus *is* the
> minimal GLib integration library I mentioned in my previous mail).
> I haven't had a chance to study its API, so I don't know quite what it
> offers - if it's sufficiently loosely-coupled that you can use the  
> GLib
> integration and ignore any utility code that turns out to be  
> unhelpful,
> that might well be a good approach.

Currently the focus is for D-Bus servers, but we do wanna extend it  
for D-Bus clients. Main focus will be dictionary helpers since they  
are a real pain with the low-level D-Bus API.

>> There is a plan to use libgdbus in BlueZ already, so BlueZ  
>> community will
>> be probably helping with maintenance.
>> Besides that you are too kind to say that dbus-glib just need a  
>> heavy cleanup,
>> if it is just like that then why nobody even start cleaning it up?
> Mainly because all its "maintainers" are really just maintainers of
> projects that use it, who end up vaguely responsible for dbus-glib  
> because
> they touched it last. I know, it's an unfortunate situation.
> For some reason the various D-Bus libraries seem to get maintainers  
> who
> have far too many projects already (and, yes, dbus-python too, and I'm
> responsible for that one).

My goal is to fix this for the non GObject based system services. They  
can all share common D-Bus helpers and the maintainers can concentrate  
on their projects and don't have to deal with D-Bus low-level details  

For BlueZ we really wanna get rid off our internal D-Bus helpers and  
hence we have libgdbus that can do it for us. If you need more helper  
functions, then please tell me and we can discuss it.



More information about the dbus mailing list