[sugar] Presence Service DBus API notes on wiki

[Dan Williams]

On Sat, 2006-07-15 at 01:20 +0200, Marco Pesenti Gritti wrote:
> >> - 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.

Yes, this should be quite possible.

> >> 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...

Thinking about it, it should be less of a problem in practice than I
initially thought.  I've changed some of the method names to reflect
this; please take a look and comment again if you feel the need.

> >   
> >> 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?

If you subscribe to PresenceService signals, then you will get
serviceAppeared/Disappeared signals for everything.  If you subscribe to
signals from a _specific_ activity object, then you'll get the signals
for services just within the scope of that activity.  Same for Buddies;
the buddy's appeared/disappeared signals will only fire for services
that buddy provides.

Dan

> >> 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