This makes sure we re-use an existing Buddy object if it's still referenced
somewhere, rather than trying to make another and fighting over the object path.
This allows us to create Buddy objects as soon as we see a contact on the
server. For contacts not on trusted servers, or seen in anonymous MUCs, we
create a Buddy identified by JID instead (so we have some way to talk
about the anonymous contact within the Sugar API).
The concept of "trusted server" means a server which we trust to validate that
users with a keyID as the username part of their JID do in fact have that key.
Currently we just pretend that olpc.collabora.co.uk does this - in future, the
school servers will do this validation by using key rather than password
authentication.
Also create Buddy object paths based on the keyID or JID (for easier debugging).
Importing dbus.glib has strange magical side-effects. Instead, make it more
explicit that the default dbus-python main loop is being set to the GLib main
loop.
It shouldn't have been applied before "services/presence: buddy: add mapping
to/from Telepathy handles" which has not yet been reviewed.
This reverts commit 78356b1956.
Conflicts:
services/presence/presenceservice.py
This causes events in the log to be annotated with the module that emitted the
message.
Before: DEBUG - root: Starting up...
After: DEBUG - s-p-s.server_plugin: Starting up...
I've used a log domain of "sugar.presence..." for the client library and
e.g. "s-p-s.activity" for the service internals.
This owner changes properties periodically so we can test out the PS's handling
of property changes. To execute, run Sugar and then make sure that the D-Bus
address is the one sugar is using (get it from ~/.sugar/default/session.info).
Then run:
build/bin/sugar-presence-service X
where X is a number 1 -> 9 inclusive. It will generate fake buddy info for that
test buddy and then start up a presence service for that buddy, changing a random
property of the buddy every 10 seconds.
