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 <[EMAIL PROTECTED]> Subject: thread summary: On Cerebro, Telepathy, yokes and whites To: OLPC Development <devel@lists.laptop.org> Message-ID: <[EMAIL PROTECTED]> 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/ _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
