using dbus in the platform

[Simon McVittie]

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

On Tue, 09 Oct 2007 at 09:55:35 -0400, Havoc Pennington wrote:
> [4] Let me qualify this, I think it could be interesting to have 
> reimplementations in these languages for use in some contexts, but I 
> think it would be better if the bindings dynamically decided to push 
> messages into the shared DBusConnection when libdbus is available. We 
> can optimize this as needed to avoid extra copies of the message, which 
> has been discussed. But the point is for a typical Linux desktop it is 
> optimal to have all the apps going through the DBusConnection in libdbus.

There are various reasons that dbus-python is using libdbus as little as
it can get away with - the 'purity' branch in git makes further moves in that
direction. I want to do a parallel-installable API break at some point in
order to avoid misfeatures of the current dbus-python that are required for
backwards compatibility (working title: "D-Sub, an unobtrusive
D-Bus implementation") and I'm undecided whether that should be
pure-Python or libdbus-based, because of considerations like sharing the
DBusConnection.

However, to make a decent Python binding, libdbus will have to get
better at being wrapped in high-level languages (the "everything returns
a DBusError, nothing aborts for reasons that can't be checked for"
approach that libdbus explicitly doesn't follow at the moment). Would
you accept patches that improve libdbus' behaviour in that respect? If I
end up using pure Python for D-Sub, I don't think there'd be any loss
from making libdbus more high-level-language-compatible anyway.

My goal is that nothing the Python programmer can do can cause libdbus
to abort (in Python, every error is meant to raise an exception, including
programmer error and OOM, but not including internal checks that would
indicate a Python implementation bug). At the moment that's impossible to
ensure.

The most glaring example is that libdbus will warn (and usually abort)
when you try to register two objects with the same object-path, but there's
no easy way to tell whether there's already an object at the path the Python
programmer has asked for. In any case dbus_is_there_an_object_here() has
the wrong semantics in a multi-threaded program - the right API would be
a dbus_try_register_object_path() that returns a
high-level-language-friendly, non-fatal error if the object path already
exists.

My other major problem with libdbus was that I spent a week thinking
about increasingly cunning ways to use weak references to avoid cyclic
references between the shared connection and the Python wrapper, and
eventually gave up. It's possible that I might be able to fix this by
tweaking the order of events during shutdown, at the cost of changing the
relative order of Python and non-Python filters (I had one solution that
would work if dbus-python didn't allow arbitrary message filtering).

It's likely that good solutions to the problems I'm facing in
dbus-python would require more of libdbus' internal API to become
public, in much the same way that Daf's dbus_message_marshal() and
dbus_message_unmarshal() expose (a copy of) the actual message data. I hope
that's not a problem.

	Simon
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net

iD8DBQFHC5NkWSc8zVUw7HYRAttRAJ0fNRccOiaSSUwTzySmKPTk4ZBL/QCfXcNy
XI9HUn+5bH2xB9thRQNM5AE=
=AFv9
-----END PGP SIGNATURE-----