Feature roadmap/File sharing

From OLPC
Jump to: navigation, search
Feature subcategory Is part of::Category:Collaboration
Requesters {{#arraymap:Peru blog|,|x|Requested by::x}}
Requirements

A way to send objects from one XO to another without a USB key, and without sharing the activity. See example of how people try to move files now at: http://blog.stone-head.org/olpc-peru-a-silent-revolution/
See also: http://wiki.laptop.org/go/Network_principles#Direct_XO-to-XO_serverless_communication.
Greg's requirements definition:

  • Must allow moving an "object" (usually thought of as a file) from one XO to another.
  • Must support all available network environments (e.g. Mesh, AP only, XS eJabberd)
  • Should allow transferring files using the existing Sugar Neighborhood tools (e.g. put a file on the journal of any other user visible in the network neighborhood).
  • Should allow moving an object to any XO visible over the network (AKA pingable) regardless of whether they are visible in the Neighborhood (due to bugs in collaboration or someone not collaborating or any other barrier which does not prevent ping).
  • May support queuing a file for transfer later. That is, add support for asynchronous sharing over time : the sharing of an effort should not require everyone to be online at once.
  • Should provide resumable downloads, so that intermittent or low quality connectivity doesn't cause transfers to fail permanently.
  • Using file transfer must work in both Salut and Gabble,
  • Allow Journal objects to be shared between buddies over link-local or Jabber
  • May enable automatic activity downloading for shared activities that aren't installed on the joining machine
  • Students and teachers have no good way to distribute files directly from one person's Journal to another. If all Activities that open a file do not implement Collaboration, then there is simply no way to transfer that file over the network.
  • Should allow access to your Journal so that any other use can see it and retrieve a file from it.
  • Should allow control of access to the XO at the file level. That is, don't expose the whole Journal, only make certain Journal entries visible.
Specification

Ideas for specifications below, when one is confirmed for implementation, please move it above this line


Owners {{#arraymap:Simon, Eben, Guillaume|,|x|Contact person::User:x}}
Priority Priority::2
Helps deployability? Helps deployability::no
Target for 9.1? Target for 9.1::no