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).
This means Buddy and its subclasses no longer need to care about
NameOwnerChanged at all.
The old code might not have worked anyway, since it was watching for
NameOwnerChanged on the session bus, but invoking NM methods on the system bus.
This means we don't need to care whether the Sugar shell is actually running -
if it is, we'll get its signals, and if it's not, obviously it can't send us
any signals!
They're not handled in the inherited do_set_property()/do_get_property(), so
won't work as properties, and there seems to be no need for them to be
properties at all.
This fixes the following assertion when importing buddy:
Warning: g_object_class_install_property: assertion `pspec->flags & G_PARAM_WRITABLE' failed
type_register(cls, namespace.get('__gtype_name__'))
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.
