[PATCH] similar change to dbus_connection_unregister_object_path
simon.mcvittie at collabora.co.uk
Wed Oct 10 10:09:38 PDT 2007
-----BEGIN PGP SIGNED MESSAGE-----
On Wed, 10 Oct 2007 at 12:33:57 -0400, Havoc Pennington wrote:
> Simon McVittie wrote:
> > As per Thiago's comments, I suggest we loosen the API contract on
> > dbus_connection_unregister_object_path too.
> Hmm... unlike the try_register this one does have a downside: if you
> have a typo in the name of the path you unregister, you'll be silently
You shouldn't be hard-coding object paths without using a #define unless
you have total confidence in your non-typoing skills :-)
One use case for this is Thiago's "replacing an object", although I
suppose what we really want there is an atomic "replace" function
(atomic in the sense that the removal and re-addition all happen under
the same lock). Or perhaps while we're adding a symbol anyway, the
_try_ functions should have a boolean parameter replace_existing.
(The object being replaced gets its unregister callback called, so it's
not as if it's unable to deal with it...)
> btw, the warning here (and for register) was just _dbus_warn, not
> _dbus_warn_check_failed, so does not abort.
It still doesn't interact well with the normal error reporting
mechanisms for high-level languages (exceptions and some sort of modular
logging, usually), so I think if we want to report the failure, we
shouldn't necessarily be reporting it by complaining to stderr. At the moment
the only way I can avoid spam to stderr is to keep track of whether I
registered or not, and this means I essentially end up with
*three* lists of registered object paths - one in libdbus, one in
dbus-python, and one (possibly implicit) in user code.
> I'm struggling to think of an example of non-broken code that
> unregisters without knowing whether it's registered.
Language bindings don't necessarily want to know what paths they've
registered - they want (their) user code to be responsible for knowing that.
However, if we used that strategy at the moment, failure looks like a D-Bus
bug, rather than a user code bug (high-level language users expect *their*
bugs to manifest as exceptions or whatever).
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: OpenPGP key: http://www.pseudorandom.co.uk/2003/contact/ or pgp.net
-----END PGP SIGNATURE-----
More information about the dbus