Announcing availability of libgdbus

[Marcel Holtmann]

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

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.

Regards

Marcel