thread summary: On Cerebro, Telepathy, yokes and whites

[Polychronis Ypodimatopoulos]

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/