Various more changes to dbus-python

[Simon McVittie]

On Wed, 10 Jan 2007 at 18:28:10 +0000, Matthew Johnson wrote:
> I assume the name was meant to be "associate with unique name rather
> than well known name". I call them peer-objects in Java, so you attach
> the object to a specific peer, rather than whoever the holder of the
> well known name is at the time.

Yes, that's the intention here - get_object_for_unique_name vs
get_object is the same difference as between dbus_g_proxy_new and
dbus_g_proxy_new_for_name, i.e. early vs late binding to the unique name
(you have to keep track of name ownership for the late-binding case
rather than just binding to the well-known name, in order to receive signals,
since the signal sender is always a unique name).

By "for_unique_name" what I really meant was "early binding to the unique
name" or "bind to the unique name of the peer which happens to own this name
at the moment" or something of the sort.

Do you think early or late binding should be the default (if it's an optional
argument) or the less elaborate name (if it's a separate method), and do
you have a better idea for the naming? follow_name_changes sounds good
as the name of a keyword argument, at least if it's not the default.

Thinking about it, early binding should probably be the default, since
the failure mode of using early binding when you wanted late binding is
less confusing than the other way round (sticking to the old object even
if the name is stolen, vs. having stateful communication disrupted by the
well-known name being stolen and the new owner not knowing what you're
talking about).

	Simon