thread summary: On Cerebro, Telepathy, yokes and whites

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
http://lists.laptop.org/pipermail/devel/2008-May/thread.html#13898

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:
http://lists.laptop.org/pipermail/olpc-sur/2008-May/000118.html

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
minimum.
- 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
starts writing.
- 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
too?) 

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.

Thanks,

Greg S

**********************************
Message: 3
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 
D-Bus API).
http://lists.laptop.org/pipermail/devel/2008-June/015238.html

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.
http://lists.laptop.org/pipermail/devel/2008-June/015239.html

Ricardo suggested that there should be someone working on a cerebro 
connection manager in parallel with jabber.
http://lists.laptop.org/pipermail/devel/2008-June/015248.html

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.
http://lists.laptop.org/pipermail/devel/2008-June/015226.html
http://lists.laptop.org/pipermail/devel/2008-June/015254.html

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 
development.
http://lists.laptop.org/pipermail/devel/2008-June/015255.html

Kim would like to figure out how to make progress on cerebro.
http://lists.laptop.org/pipermail/devel/2008-June/015261.html

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.
http://lists.laptop.org/pipermail/devel/2008-June/015262.html
http://lists.laptop.org/pipermail/devel/2008-June/015258.html

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.
http://lists.laptop.org/pipermail/devel/2008-June/015274.html

Tomeu also suggested getting this summary together (thanks!) and that it

may make sense to separate discussion on the API from discussion on the 
current implementation.

I hope I captured the most important parts of this threads, feel free to

blame me if I failed in any parts.

Pol

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