#8171 HIGH 9.1.0: Possible XO to XO object transfer mechanisms for sharing data (was: Classroom feedback: Need to share a file from one XO to another)

[Zarro Boogs per Child]

#8171: Possible XO to XO object transfer mechanisms for sharing data
---------------------------+------------------------------------------------
   Reporter:  sj           |       Owner:  Eben         
       Type:  enhancement  |      Status:  new          
   Priority:  high         |   Milestone:  9.1.0        
  Component:  sugar        |     Version:  not specified
 Resolution:               |    Keywords:               
Next_action:  communicate  |    Verified:  0            
  Blockedby:               |    Blocking:  6932         
---------------------------+------------------------------------------------
Changes (by Eben):

 * cc: marcopg, wad, martin.langhoff (added)
  * priority:  normal => high
  * next_action:  never set => communicate
  * component:  not assigned => sugar


Comment:

 There are a few ways we can think about transferring files:

 1. '''Synchronous:'''

 This is the most straightforward, the most direct, and the first option we
 should provide.  The action is quite direct, and involves selecting the
 person to send something to, and what to send eg. "Send <this object> to
 <my friend>."  The transfer is synchronous, and depends on network
 connectivity.  Ideally, our transfer system will also include a recovery
 system by which interrupted transfers can be resumed.

 2. '''Asynchronous, server:'''

 The next obvious method of transferring files is in the form of email
 attachments.  More generally, we depend on a server to hold the file and
 later make it accessible to the other person. This solution can time shift
 the transfer, and also help to get around firewalls.  It doesn't, strictly
 speaking, depend on email, but it could.

 The real question is if we want to implement, in the background, a
 transparent system for the recipient which provides this service (and
 shows alerts, handles the downloads, etc. automatically).  If not, do we
 still create a service for the sender which wraps the file into an
 attachment and sends it off to another?  This depends on mapping our
 notion of identity to an email address, of course, which can complicate
 things some.  I like the idea of an OS provided, transparent, asynchronous
 message/object passing system, though.

 3. '''Asynchronous, messenger:''' We could also implement an asynchronous
 message passing system which depends on no server at all.  Otherwise known
 as the 'briefcase idea', it involves wrapping a message up into an
 encrypted bundle and then passing that bundle to a) peers and/or b) the
 school server for future delivery to the intended recipient.  Of course,
 this uses space on the messengers system while in transit, instead of the
 server, so it would have to be opt in.

 In other words, one XO might send out a message to others asking "does
 anyone here know of <buddy X>".  They could then reply with information
 such as the number of times they have seen <buddy X>, the last time they
 saw <buddy X>, and/or the frequency with which they have seen <buddy X>
 (in a period of a week, perhaps).  Then, the first XO could request to one
 or more of the respondents that seem to see <buddy X> reliably enough to
 carry this message.  They would get a "messenger invitation", which they
 could accept or decline, and then the next time they see <buddy X>, they
 would send him an invitation to accept the message, and then remove it
 from their machine once sent (or declined).  Naturally, the school server
 could also offer (and automatically agree) to store the message as well,
 eliminating the burden on kids.

 This system could also provide a way, for instance, for brother Bob to ask
 sister Alice to turn in his homework to his teacher while he's out sick.
 There are lots of other reasons that make this a compelling idea.

-- 
Ticket URL: <http://dev.laptop.org/ticket/8171#comment:3>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system