[PATCH] similar change to dbus_connection_unregister_object_path

[Simon McVittie]

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

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

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

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

iD8DBQFHDQdSWSc8zVUw7HYRAmc/AJ9BEK5I7Ugi2FUldAV60cIXD4U6dwCdH6M6
c4GFgrOzV6hbqqFBJ9Ix+dY=
=mUGi
-----END PGP SIGNATURE-----