[sugar] Presence Service DBus API notes on wiki

[Marco Pesenti Gritti]

- PresenceService

getBuddyByName(name)
getBuddyByAddress(address)

These somewhat open the problems of identity... We should discuss it at 
some point. Maybe next demo.

- Buddy

getProperties()

Why not getters for each property?

getBuddyActivities()

Buddy seem somewhat redundant here. Also gives the impression the buddy 
is owning these activities, while he is actually just partecipating. 
Maybe getJoinedActivities?

getBuddyService(type)

 >Gets one service of a specific type. Only one service of each type may 
be offered by each >buddy for each activity. i.e., services are unique 
within the scope of both a buddy and an >activity

I'm a bit confused here. How this is activity scoped?

Also Buddy is probably redundant.

- Service

getProperties()
getPublishedValue(key)

Is there a reason for the incosistent naming?

- Activity

> Any comments? :)  Can you think of any operations that we currently need
> to do that won't fit into this API?  We don't need the
> track_service_type()/untrack_service_type() stuff since the PS will now
> be global; though that stuff could be done in the thin Python shim that
> we'll need to make the dbus stuff somewhat simpler.
>   
What is the use case of track/untrack if we have an Activity service 
that already filter the activity specific services?

getActivityServices()
getActivityServicesOfType(type)
getActivityBuddies()

Activity seem redundant here to me.

We need to think how to integrate presence service inside 
sugar.activity.Activity.
There is the name clashing between sugar.activity.Activity and 
sugar.presence.Activity which makes things difficult. 
sugar.presence.Activity is actually a presence service, scoped to the 
activity. So it might be ActivityPresenceService. (GlobalPresenceService 
and ActivityPresenceService could also implement a PresenceService 
interfaces, but that might taking it too further).

Marco