Announcing availability of libgdbus

[Simon McVittie]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 17 Apr 2008 at 00:45:39 -0300, Luiz Augusto von Dentz wrote:
> >  >> 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.

Like you say, it should have been called dbus-gobject in the first place,
really, although it's far too late now.

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.

(If I ever have time to redo the dbus-python API like I've been planning
to for approximately forever, I intend to follow a similar model -
low-level glue + *optional* high-level object-model integration. Flying
pigs are probably more likely at this point, though.)

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

telepathy-glib's wrappers around dbus-glib could be seen as a start to
cleaning it up - I haven't had a chance to push for changes in
dbus-glib that would make it saner to work with (or indeed incorporating bits
of telepathy-glib into dbus-glib), since I've been busy with my own deadlines
and design issues. You know how it is, I'm sure...

    Simon
-----BEGIN PGP SIGNATURE-----

iD4DBQFIByVTWSc8zVUw7HYRAjecAJ9JNzcTzrUNazQoacC5EbBFCCHUPQCYwAgE
XsHVwWYh8et5Unn1JL+LRw==
=HubR
-----END PGP SIGNATURE-----