[sugar] Presence Service DBus API notes on wiki

[Marco Pesenti Gritti]

>> - Buddy
>>
>> getProperties()
>>
>> Why not getters for each property?
>>     
>
> Because latency sucks when you have to get each property.  We found with
> NetworkManager that if you bundle up the most common properties into one
> call, things go more smoothly.  Tradeoff of latency versus efficiency
> here.
>
>   
Ok... I'd still prefer separate getters in the python layer.
>> getBuddyActivities()
>>
>> Buddy seem somewhat redundant here. Also gives the impression the buddy 
>>     
>
> Right; but notice that there are a _lot_ of similarly named calls for
> each object.  For example, if the calls weren't verbose, the PS would
> have a getActivities() call, and the buddy would have a getActivities()
> call.  Similarly, all three of the PS, Buddy, and Activity objects would
> each have a getServiceOfType() and a getServices() call.
>
> I thought that would be confusing since the only difference between
> these method calls is the scoping.  Better to show in the method name
> exactly what's being retrieved.
>   
Maybe...
>   
>> 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?
>>     
>
> Activities "contain" services and Buddies.  It's all a bit confusing
> since this is attempting to provide structure over the mDNS flat service
> space.
>
>   
I see. Yeah, a bit confusing... But I don't think it will be too much of 
a problem in practice.
>
>> - Service
>>
>> getProperties()
>> getPublishedValue(key)
>>
>> Is there a reason for the incosistent naming?
>>     
>
> Well, I thought for a while about this one.  There are two "property
> lists" here.  The first is the internal service properties, what we
> might think of as the member variables of the object.  Those are things
> like address, name, type, domain, etc.  The second are the ones that are
> retrieved from the DNS TXT record after the service has been resolved.
>
> They are distinct, and I didn't want to mix the two together.  I would
> have liked to use "properties" for the TXT record ones, but I was
> already using properties for the buddy object.  "Attributes" is too
> generic, just like properties.  Any other suggestions here?
>   
Ok, it's not too bad. I think I was confused mostly because I had 
current API in mind.
> The case for track/untrack is that currently, all service announcements
> will be delivered to the activity,
What do you mean with all services here? All services in the activity 
scope? That's what I'd guess reading the API... I mean, we have an 
activity object with serviceAppeared/serviceDisapperead signals. I'd 
expect only the services inside the context of the activity to be 
reported there. Am I missing something?
>> 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).
>>     
>
> I thought about that too; we have the local list of activities that the
> Shell knows about that are running locally (ie, you have joined them
> otherwise they wouldn't be running locally), and then the
> PresenceService list of activities that (a) you _could_ join or (b)
> already have joined.
>
> So the PS list of activities is actually a superset of the local set of
> activities that used to be kept in the shell.  Not quite sure about what
> to do there.  What information do we actually need about local
> activities, like what we used to keep in the shell?  Obviously the
> tab-related icon & title setting stuff is gone, but what else? 
For local activities we need at very least icon and title. I think we 
can just get these using the wm... We may want some sort of thumbnail of 
the current content too. We should probably use DBUS to get these.

I think the same should be for remote activities. The icon could be 
mapped to the activity type locally, so that we avoid to get it from the 
network.
The title is currently stored in the TXT. This should be probably 
abstracted in some way inside Activity rather than having each activity 
do it in his join().
The thumbnail thing get more complicated, we would have to fetch it from 
one of the buddies which joined the activity... Diana design is not 
using thumbnails atm though, so I'd rather delay this...
>  What
> mechanism do we use to allow the Web activity to send a link to the chat
> activity like we used to do, for example?
>   
Probably a dbus service like it was before (need to figure the activity 
API for this)...
I'm not sure how this relates to the presence service though?

Marco