[sugar] Presence Service DBus API notes on wiki
Marco Pesenti Gritti
Fri Jul 14 11:53:12 EDT 2006
These somewhat open the problems of identity... We should discuss it at
some point. Maybe next demo.
Why not getters for each property?
Buddy seem somewhat redundant here. Also gives the impression the buddy
is owning these activities, while he is actually just partecipating.
>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.
Is there a reason for the incosistent naming?
> 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?
Activity seem redundant here to me.
We need to think how to integrate presence service inside
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).
More information about the Sugar-devel