[sugar] Presence Service DBus API notes on wiki
Mon Jul 17 11:02:30 EDT 2006
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.
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.
> >> 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
> 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?
More information about the Sugar-devel