On Cerebro, Telepathy, yokes and whites (was Re: cerebro in sugar)

[Morgan Collett]

On Tue, Jun 10, 2008 at 19:05, Polychronis Ypodimatopoulos <ypod at mit.edu> wrote:
> Like Michael pointed out, "there are few people at OLPC who understand
> and enjoy telepathy". I think this is an understatement. Personally, I
> think that Collabora was very pressed to get something working on the
> laptop and the resulting presence stack looks like one hack on top of
> another. For example, there are tons of abstraction layers, yet
> activities have visibility (while they shouldn't) on how telepathy works
> (since telepathy is only a dependency to sugar, this should not be the
> case). Also, the presence service needs to understand if it should
> switch from salut to gabble, but the broadcast storm caused by salut
> won't let XO get an IP address through DHCP, which would mean that
> there's a school server around and..... you get the picture! The current
> plan to attack scalability problems is implementing gadget from scratch
> which, if I understand correctly, is a plug-in to jabber which already
> has many problems of its own. Are we sure we're investing our limited
> time in the right direction?

I started working for Collabora on the presence stack just over a year
ago. I'll try to give some context to the presence stack architecture
based on my experience since then.

Presence Service (PS) predates the use of Telepathy. When I started on
this, PS was maintained by Dan Williams (Redhat). It was then
maintained by Simon McVittie (Collabora) and then myself when Simon
switched projects. When I left Collabora, Guillaume Desmottes
(Collabora) took over as primary maintainer, although I continue to
contribute.

PS has a certain amount of cruft in the codebase from before Telepathy
was integrated. There are some design aspects that would be politely
considered "interesting", such as the fact that there are two entirely
different mechanisms for tracking who is in an activity (so we can
show the buddies clustered around the activity icon in Neighborhood
view) - before we join a shared activity we need to track who's in it
by their announcements of their activities, but when we are in a
shared activity, we can see the other participants directly. When
joining an activity, we switch from the one mechanism to the other.

For your interest, outside of Sugarland, the component in the
Telepathy architecture which is most directly equivalent to PS is
called Mission Control (see the diagram on
http://mission-control.sourceforge.net/).

When I started with Collabora, activities contained a lot of Telepathy
code. In fact, Connect was the only collaborative activity, and it was
our test case for the implementation. A fair amount of my efforts with
respect to the presence stack have been to simplify the API or
collaboration mechanisms available to activity authors. This has been
done by pushing the Telepathy functionality into PS where possible, or
sugar.presence which is the client to the PS D-Bus API for python
activities.

At this point, there remains code in activities to deal with the setup
of Tubes. In a further development cycle, after 8.2 / Sugar 0.82, I
plan to simplify that further so that all collaborative python
activities get a D-Tube set up automatically, and don't need any
boilerplate for that at all.

I hope this gives some explanation of why there is Telepathy code in
activities. Even with all the current boilerplate removed, it should
still be possible for activities to interact directly with Telepathy
should the activity author want to do something not provided by the
framework.

Regards
Morgan