thread summary: On Cerebro, Telepathy, yokes and whites
Greg Smith (gregmsmi)
gregmsmi at cisco.com
Fri Jun 13 08:49:22 EDT 2008
Hi Poly et al,
Thanks for the summary and documentation.
After the last round on this subject
I exchanged some e-mails with a teacher in Uruguay to get a better sense
of exactly how they want to use the XO in class to collaborate. See:
Here is the use case I got out of that exchange:
- The class has 10 - 25 kids in the second grade each with an XO. There
are 100 - 200 Xos in the school. Each class can join a different channel
and time share (TDM :-)to keep the number of Xos per channel to a
- One class (10 - 25) connects its Xos to the mesh (they do it by
clicking the round mesh icon but they will do whatever works)
- There is a wireless access point in the school and they see several
other wireless Aps so there is some RF background.
- One kid opens write (also want to use paint) sets it to share and
- In the neighborhood view the other students see the write icon and
join the activity by clicking on it.
- All the children start to write text and add pictures at more or less
the same time
- Each kid wants to save the file in their own journal at any time (this
is where it crashed when they tried it with write)
- After saving to the journal they want to see the shared document
again. Its OK to require them to leave the share to open their own local
copy as long as it doesn't "crash" if they do it out of order (what is
supposed to happen if you are sharing a document then open a new one
Is that a well defined use case that you can turn in to an end to end
test case? If not, what additional information or details do you need?
My impression is that the teachers don't really care about the
technology as long as they can do what is described above. I don't know
exactly what software they have on their school servers (e.g. not sure
about jabber). If we can tell them what software, configuration and
steps they need to take in order to run a class as described that would
be a very good start.
I understand there is a write bug which is probably responsible for
their issue. You can substitute paint or another activity if it helps
isolate the collaboration aspects from the activity aspects.
This can be something we test for a future release if its not something
that is possible now. So please include build #s and time frames in any
response. I wont say anything to the teacher about what is possible
until I see a very solid reproduction of their environment and use case.
I'll keep digging up real use cases and sharing them so let me know what
kind of info you need to turn them in to test cases.
No reference to Cerebro, telepathy etc, but I hope that helps. Comments
and questions welcome.
Date: Wed, 11 Jun 2008 14:22:10 -0400
From: Polychronis Ypodimatopoulos <ypod at mit.edu>
Subject: thread summary: On Cerebro, Telepathy, yokes and whites
To: OLPC Development <devel at lists.laptop.org>
Message-ID: <485017D2.5070903 at mit.edu>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
This is a summary (a la Michael) of the cerebro/telepathy thread.
Pol brought up the issue of how the collaboration stack is currently
implemented, that there should be a dead-simple networking API for
activity development and proposed someone taking the lead in
implementing a connection manager for cerebro (which currently offers a
Ben suggested that there is no need to abstract telepathy further
because it's an abstraction layer in itself. Instead, API changes should
be proposed, if any exist.
Ricardo suggested that there should be someone working on a cerebro
connection manager in parallel with jabber.
Marco and Tomeu agreed that there should be a cerebro connection
manager, Marco conceded to getting cerebro in joyride, but disagreed
with adding an abstraction layer between telepathy and sugar/activities
on the basis that telepathy is abstraction layer in itself and we must
live with what is currently available for lack of resources and because
compromises are often made in large software projects.
Scott brought up the issue of children invariably trying to develop a
multi-player game on sugar and failing because of the complexity of the
collaboration API. Marco agreed with this problem and recognized the
need for a python layer above telepathy/cerebro that can be invoked
without DBus, while a lower level DBus-based API will be used by
non-python activities. Both Marco and Scott saw the need for extensive
tutorials and examples on how to use any networking API for activity
Kim would like to figure out how to make progress on cerebro.
Robert characterized telepathy primarily as an API to a variety of
functionality and different communication mechanisms, recognized some
problems in the implementation and the need for cerebro as one of the
plans to deal with those problems. He also went through the history of
how D-Tubes and stream tubes came about and noted that the requirements
were not really clear when their (D-Tubes and stream tubes)
implementation started. He also recognized the need to hide some of the
complexities of network programming by adding a simplifying layer on top
of telepathy, or by extending the current telepathy API.
Finally, Morgan went through the history of how the Presence Service was
implemented, that it predates the use of telepathy and that it contains
some "interesting", to put it politely, design aspects. He also went
through his efforts to simplify the implementation of collaboration in
activities by pushing the telepathy functionality from the activities
into the PS where possible and his plans to simplify further
collaboration in activities.
Tomeu also suggested getting this summary together (thanks!) and that it
may make sense to separate discussion on the API from discussion on the
I hope I captured the most important parts of this threads, feel free to
blame me if I failed in any parts.
MIT Media Lab
Tel: +1 (617) 459-6058
More information about the Devel