Sugar presence refactor

  This page is monitored by the OLPC team.

Capabilities

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

• A list of Buddies Sugar knows about
• A list of services each Buddy provides, of two types:
  • services filtered by types the Activity is interested in
  • standard "auxiliary services" like Chat and VOIP, that are common to all activities

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.
• Activity: not really provided by the PresenceService, but the main Sugar activity object. Each Activity is assigned a UID by the Shell, and provides this UID to the PresenceService. The PresenceService uses the UID to filter service advertisements and activity advertisements. All service advertisements that contain this activities UID are considered to be in the same "group". For example, a shared Web Activity might have the title "History Class", reference a shared document called "HistoryClassHomepage", and include all children in the history class. Shared activities are not concretely or centrally defined, they are merely the aggregation of everyone who expresses interest in the specific resource.

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.

Shared Activities

Shared Activities are activities in which a resource is common to more than one child/laptop. This is accomplished through mutual advertisement of the same mDNS service.

The Sharing Process

1. Tommy opens a new Web activity. The activity is assigned the UID 12345 by the shell, and is implicitly unpublished.
2. Tommy goes to the "Butterfly Information" page and clicks the "Share with Everyone" button
3. Tommy's Web activity asks its PresenceService instance to create a new Activity Service advertisement of the type "_web_olpc._udp"
4. The Web activity's PresenceService creates the new Activity Service advertisement, giving it a real service type combining the activity's UID and the requested type: "_12345_web_olpc._udp.local", and asks Avahi to publish it
5. Jill's laptop hears Tommy's laptop announce a new Web activity
6. Jill's Everyone page adds the Tommy's Web activity's "Butterfly Information" web page announcement to its "What's going on" list
7. Jill clicks the announcement because she's interested in butterfies
8. The Everyone page creates a new Web activity, pointing to "Butterfly Information" using the _same_ UID as the Web activity on Tommy's computer
9. Jill's new Web activity, because it was started from a published, public advertisement, asks its PresenceService to create a new Web Activity Service advertisement, using its UID (which is the same as Tommy's Web activity)
10. Jill's PresenceService publishes the Web Activity Service advertisement
11. Tommy's Web activity PresenceService hears the announcement from Jill's computer, and because it has the same UID as Tommy's Web activity, adds Jill to this activity's presence group
12. Now, either Jill or Tommy may publish further service advertisements, each of which

By default, the PresenceService will only alert its client Activity of services that the client activity cares about. When the activity starts the PresenceService, it registers its UID with the PresenceService, and the PS will then filter all services through both the activity's UID and the service types the activity requests to be tracked.

Service Advertisement Mapping

An mDNS service advertisement is considered to belong to the Shared Activity as long as it contains the UID of the shared activity in its service type. For example, given a shared activity with a service type of "_12345_web_olpc._udp", any other service from any Buddy that begins with "_12345_" is considered to belong to that shared activity. i.e., "_12345_chat_olpc._udp" is the group chat for everyone who is "present" in that shared activity. Likewise, "_12345_voip_olpc._udp" is the VOIP conference chat for everyone in that shared activity.