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

[Marco Pesenti Gritti]

On Tue, Jun 10, 2008 at 7:05 PM, 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).

Hello Polychronis,

Really? My understanding is that telepathy is dependency for
activities to, the abstraction layer they use to communicate on the
network.

> 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?

The whole software stack is full of compromises, we have to make them
for a couple of reason:

* We have finite (read ridiculously limited) time and resources. On
the short time a decent user experience is more important than a
perfect architecture.
* We have to interoperate with existing software for a bunch of good
reason that I'm not going to explain here.

> 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!

Sounds totally like a good idea to me, since you tried to do it
yourself but was not able to. Everyone seem to have an high opinion on
Cerebro and testing showed impressive results so far, so I think it's
worth investing some of the Collabora time into 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.

This sounds like a bad idea to me for several reasons:

* The abstraction layer needs to be accessible to non-python
activities. Unless you want to expose it through DBus, you will have
to write it in C (with python bindings). And if I'm not mistake
Cerebro is written in python.
* Good or bad (I can't have an opinion since I never looked deeply
into it) telepathy is already and abstraction layer. We should fix it
or replace it, if it has problems, not hide it under another one.
* I haven't seen any concrete technical argument against telepathy *API* so far.
* We have already a bunch of activities out of there which are using
the current API, so it's kinda late to introduce an abstraction layer
to avoid breaking them in the future.

If you think telepathy API is irremediably broken, I suggest you focus
on coming up with an alternative which meets all the requirements
(included working for non python activities) and at the same time it's
technically superior to the telepathy one (enough to be worth an API
break of these dimensions).

> 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?

I don't see any issue in doing that.

Just my 0.02$

Cheers,
Marco