#4406 HIGH Future : XO leaves trash on USB sticks

[Zarro Boogs per Child]

#4406: XO leaves trash on USB sticks
------------------------+---------------------------------------------------
  Reporter:  gnu        |       Owner:  tomeu                            
      Type:  defect     |      Status:  new                              
  Priority:  high       |   Milestone:  Future Release                   
 Component:  datastore  |     Version:  Development build as of this date
Resolution:             |    Keywords:                                   
  Verified:  0          |    Blocking:                                   
 Blockedby:             |  
------------------------+---------------------------------------------------
Changes (by Eben):

 * cc: christianmarc (added)


Comment:

 This is one of those "really hard questions".  In light of the new Journal
 designs, I'm tempted to say that either:

  1. We only store the object (the file), so as to allow basic transfer of
 well known file formats to others and also to the non-XO world.  This is
 in keeping with the notion that I could either invite someone to join in a
 collaboration on a drawing (in which case they get the associated state
 and a matching activity ID) or give someone a drawing I made (in which
 case the get only the object, and no activity state or associated
 collaboration.  This seems to be the simplest answer.

  2.  A slightly more appropriate solution in light of the new Journal
 design is to treat the objects (files) separately from an "activity
 closure" (I'm just introducing this term now).  Basically, resuming from
 the activity-centric view will restore the state of the object and the
 activity as it was last edited.  On the contrary, opening a file from the
 object-centric view would simply start a new activity instance with the
 selected file, with a new activity ID and no associated state.  Likewise,
 we can carry this over to external devices by treating copied objects
 (from object-centric view) as simple files, while wrapping up an activity
 closure as, perhaps, a zip bundle containing the object file(s), a state
 blob, and perhaps a .info or similar to tell Sugar how to put it back
 together later.

 As a side note, we should attempt to preserve metadata as already
 supported by various file formats (ID3, EXIF, etc).  Would this require
 duplication of metadata information?  Could we install proxies for
 metadata which automatically set such fields when activities modify a
 particular key which matches the well defined schema?  Sorry for the
 diversion, but it seems to relate at least in part to the above topic.

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