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

[Polychronis Ypodimatopoulos]

Tomeu and Marco,

For the history, both me and another student from MIT tried to implement 
a connection manager back in January but gave up after a couple of 
weeks, even with significant help from Daf. We don't claim to be expert 
python programmers, but spending two weeks on something and still not 
even having understood what needs to be implemented (let alone 
implementing it) to get a connection manager going, or exactly how 
telepathy works was quite frustrating. What is more frustrating is that 
the telepathy API is no secret, but it seems that there is some distance 
between the API and how the presence service and telepathy really work 
on the laptop.

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?

Personally, I don't think this is entirely Collabora's fault. I also 
think that if you want to have "distinct yoke and white", this is where 
you should start: Make telepathy dead-simple to understand by reading 
the code, not the API. I did a funny activity showing XOs and their 
relative distance 
(http://www.olpcnews.com/hardware/wireless/xo_space_where_you_are.html) 
almost a year ago in a couple of afternoons, when there was no hint of 
Sugar APIs (not even hippocanvas!) because it was dead-simple to inspect 
other activities' code and how sugar works.

Which brings us to cerebro. Since I got stuck with telepathy, I decided 
to circumvent telepathy altogether, at the very least as a proof of 
concept for cerebro's functionality. The result is an API 
(http://wiki.laptop.org/go/Cerebro#Programming_API ) that offers not 
only presence and data sharing between activities, but is also a 
/complete collaboration framework/: you can share/join activities, get a 
list of all currently shared activities and users participating in them, 
invitations, out-of-band chat, interoperability with Windows, embedded 
Linux and OpenMoko (collaboration tested on all these platforms) and 
most importantly, scalability.

Now, the nightmare strikes back: I have to go back to implementing a 
connection manager. Tomeu has a point: "How many people you know that 
understands and enjoys any of mozilla, gtk, pygtk, abiword, X, cairo, 
etc?". But when did OLPC start doing compromises? And if you have to do 
a compromise, it's better not to do it at such a critical point like the 
collaboration in sugar.

Here's what I propose:

1) Someone should take the lead at implementing a connection manager and 
I will actively participate, not just by adapting cerebro's API if 
necessary, but also with implementing the necessary stubs for the 
connection manager. But the skeleton must be well understood by the 
person implementing it!

2) Make provision in both sugar and activities so that there is a clear 
abstraction from telepathy so that _if_ a better collaboration stack 
comes along, telepathy won't be "hardcoded" in sugar. This mainly 
involves documenting the existing calls from sugar/activities to 
telepathy (and objects returned thereof) and signals provided by telepathy.

3) Get cerebro into joyride which will help a lot with the upcoming 
multi-hop tests: humans will be operating and updating their XO that 
participates in the mesh in MIT campus, so I think it is critical to 
have cerebro in joyride. Am I wrong?

Pol

-- 
Polychronis Ypodimatopoulos
Graduate student
Viral Communications
MIT Media Lab
Tel: +1 (617) 459-6058
http://www.mit.edu/~ypod/