#3431 HIGH First D: Need to be able to share objects in the mesh, not just activities

[Zarro Boogs per Child]

#3431: Need to be able to share objects in the mesh, not just activities
--------------------------+-------------------------------------------------
  Reporter:  kimquirk     |       Owner:  marco                 
      Type:  enhancement  |      Status:  new                   
  Priority:  high         |   Milestone:  First Deployment, V1.0
 Component:  sugar        |     Version:                        
Resolution:               |    Keywords:                        
  Verified:  0            |  
--------------------------+-------------------------------------------------
Changes (by cscott):

 * cc: cscott, sj (added)


Comment:

 The Trial-3 version of this "feature" is, in my opinion, implemented on
 the school server with the backup mechanism.  We provide links to the
 school server which will have a list of all the objects backed up by a
 kid.  If you want to share a file, find it on the school server and
 download it via the browser; it shows up in the journal as usual.  This is
 well within reason for Trial-3 and FRS.

 I strongly oppose hacking together some sort of "better" solution by FRS.
 We need to sit down and come up with a *real* design for (the UI for)
 versioned objects, global sharing, local caching, hooks to CDNs, etc.  We
 will not be well-served by rushing implementation without a solid design.

 SJ has (in a posting on devel@) said: "Right now the mesh view supports
 pretty synchronous activities - either you are actively doing something
 with someone, or you very recently were.  Eben discusses sharing objects
 as "a snapshot, and not in any way permanently linking/publishing the file
 (It should be a momentary button)"...  Also worth considering are
 meshboard sharing of
 objects with expiration date and more permanent sharing of objects."

 I'll suggest that a good use case for "more permanent sharing" is the
 "sample files" currently distributed with a number of activities (Turtle
 Art, Pippy, etc).  I submit that we should unify our conceptual model:
 "sample files" are just files shared by the authors of those programs.
 Pippy shouldn't have a separate load dialog for "sample files", rather it
 should just know that there's a person "cjb" who has some good stuff for
 kids to look at.  We preload content on the laptops to allow these samples
 to be visible even when disconnected, but the UI should be identical to
 cjb sharing files with you.  If people in your local school have better
 sample files, you should be able to get to them with the same mechanism.

 The above paragraph is a little out-of-scope for this bug, but I hope it
 demonstrates that there are important fundamental issues remaining to be
 decided, whether you agree with my idea of how it "should" work or not.
 We shouldn't spend valuable pre-FRS implementation effort on this until
 we've agreed on a design.

-- 
Ticket URL: <https://dev.laptop.org/ticket/3431#comment:14>
One Laptop Per Child <https://dev.laptop.org>
OLPC bug tracking system