thread summary: On Cerebro, Telepathy, yokes and whites

Fri Jun 13 10:51:22 EDT 2008

Greg,
I am adding the 'testing' mailing list. We can use this 'real life'
information for generating Use Cases and test cases but we will
probably need to simplify it.  There are too many things going on in
this particular case. We have some use cases for school scenarios in
some of these links:

http://wiki.laptop.org/go/Tests/Connectivity_and_Collaboration - use
cases in classroom
http://wiki.laptop.org/go/Networking_scenarios - major types of scenarios
http://wiki.laptop.org/go/Collaboration_Network_Testbed - 100 laptop testbed

As well as generating use cases, this 'real life' scenario tells us
that we have not conveyed what SHOULD work properly to people on the
ground - as what they are trying to do is not even possible in today's
builds. We've known that communications is a problem, but it
emphasizes that we need to figure out some solutions... and telling
this particular teacher, for instance, that what they are trying to do
won't work, is not the right answer.

Also, from a support perspective, it is really important when we get
feedback or help requests directly from teachers in country that we
try to get them in touch with their local support people - or we try
to include the local tech support people. As Wad as identified in the
past, if we try to help people where we really don't understand the
local constraints or the RF layout we are more likely to make things
worse than to actually provide help. With large country deployments,
the first level of help needs to come from in house support.

Thanks for bringing this up, Greg. It emphasizes a lot of things we
need to address.

Kim

On Fri, Jun 13, 2008 at 8:49 AM, Greg Smith (gregmsmi)
<gregmsmi at cisco.com> wrote:
> 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/
> _______________________________________________
> Devel mailing list
> Devel at lists.laptop.org
> http://lists.laptop.org/listinfo/devel
>