Sugar presence refactor

Capabilities

Sugar's presence service should provide the following information to Activities:

• A list of Buddies Sugar knows about
• Which network-aware Activities each buddy makes available, for example:
  • chat
  • VOIP
  • wiki

The presence service should handle all details of gathering buddy presence information, and allow individual Activities to access that information through a fairly simple, straightforward API layered on top of Avahi and dbus.

It should also provide the means by which Activities advertise their presence to other laptops.

Structure

The presence service will provide a few objects:

• PresenceService: singleton object providing an interface to the presence service. Responds to Activity request for buddies and groups based on specified criteria. For example, an Activity could request a list of every Buddy available to chat with, or a group called "HistoryClass". This object also responds to request from Activities to publish new services to others on the network.
• Buddy: each buddy object represents a distinct child using a laptop. In reality, it encapsulates information about a specific Sugar instance running on a laptop. The Buddy object will provide access to a list of Activities the Buddy makes available to others.
• Group: a group encapsulates one or more Buddies that are interested in the same resource. For example, a Group might have the title "History Class", reference a shared document called "HistoryClassHomepage", and include all children in the history class. Groups are not concretely or centrally defined, they are merely the aggregation of everyone who expresses interest in the group.

Implementation

For the moment, the presence service will be a python module that is private to each Activity. In the future it will likely be a dbus service merged into the shell. Only one presence service object will be initialized in any given Activity through use of singletons.

Presence is merely a layer on top of Avahi that provides a more useful abstraction to Activities. Since with Avahi/ZeroConf, there is no concept of service "owners," it is up to the Presence service to determine which published services are owned by the same Buddy/laptop/child. We're doing this right now by simple name matching and IP address checking in the mDNS records, but this is quite easy to spoof and should be changed later to a more robust scheme.

Say we have two Activities, chat and wiki. Chat uses the ZeroConf services _chat._sugar._udp for multicast group chat, and _chat._sugar._tcp for small quick chats. The wiki activity uses the _wiki._sugar._tcp service. Each Activity requests the presence service to advertise their services so that other children may find them.

Sugar is now advertising three ZeroConf/mDNS service types:

• _chat._sugar._udp
• _chat._sugar._tcp
• _wiki._sugar._tcp

Because these three service advertisements come from the same IP address, and have the same service name, the presence service on other laptops will aggregate the 3 services under the same Buddy, who is identified by the common name and IP address.

Other laptops on the network are advertising their own Activities. Each Activity notifies the presence service of the of the names of ZeroConf services in which it is interested in viewing. Obviously the wiki would like to see other wikis, and therefore requests the presence service to look for _wiki._sugar._tcp. The presence service will then update its internal lists of Buddies and Groups when new presence events for the requested service names occur, and notify the interested Activities as well.