thread summary: On Cerebro, Telepathy, yokes and whites

Fri Jun 13 12:02:26 EDT 2008

Hi Kim,

Thanks for the comments and links.

FYI I didn't make any representation about what is supported or what
should work now or in the future. I just asked what they want to do.

Wad did get the Latu people on the list and they have started
participating, somewhat.

We need to keep working the proper support channels and using them to
improve the communication of what will work. I'll focus on that. 

In the mean time, I hope to maintain a good relationship with the
teachers to help uncover more desired use cases, without interfering in
the support process. 

Thanks,

Greg S

-----Original Message-----
From: kim.quirk at gmail.com [mailto:kim.quirk at gmail.com] On Behalf Of Kim
Quirk
Sent: Friday, June 13, 2008 10:51 AM
To: Greg Smith (gregmsmi)
Cc: devel at lists.laptop.org; testing at laptop.org; joe
Subject: Re: thread summary: On Cerebro, Telepathy, yokes and whites

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
>