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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
