[PATCH 09/17] dbus/_dbus.py: in SignalMatch, use get_name_owner()

[Simon McVittie]

Oops, forgot to direct my reply to the list:

On Mon, 30 Apr 2007 at 17:52:02 -0400, John (J5) Palmieri wrote:
> Is this right btw?  What happens if the bus name changes owners but the
> original match was for the bus name and not the unique name?

Here's how it should work after all 17 patches, let me know if it
doesn't seem to:

If we're on a simple Connection, we blindly match against whatever the
user asked for, because we don't know what policy the pseudo-bus might
be using. (Telepathy's Tubes will use strings that look like unique
names, to avoid upsetting less tolerant clients.)

If we're on a BusConnection and the user asked for a unique name, we
match against it, and don't bother adding a NameOwnerChanged rule.

If we're on a BusConnection and the user asked for a well-known name, we
have to resolve it to a unique name, because the sender will always show
up as the unique name. However, SignalMatch doesn't actually know about
buses, so it sets sender_unique to the well-known name (somewhat
misleadingly). Immediately afterwards, the BusConnection alters the
SignalMatch's sender_unique by resolving the well-known name to a unique
name. It also sets up a NameOwnerChanged match so the sender_unique will
be kept up-to-date in future.

Some bugs I should fix tomorrow, thinking about it:
 * add the NameOwnerChanged match rule before calling GetNameOwner, to
   avoid a race
 * call GetNameOwner asynchronously

I'll add a method watch_name_owner which does both of the above.

	Simon