#4725 HIGH Never A: We need an Incremental Auto-keep API

[Zarro Boogs per Child]

#4725: We need  an Incremental Auto-keep API
-------------------------+--------------------------------------------------
 Reporter:  Eben         |       Owner:  tomeu         
     Type:  enhancement  |      Status:  new           
 Priority:  high         |   Milestone:  Never Assigned
Component:  sugar        |     Version:                
 Keywords:  update.2?    |    Verified:  0             
-------------------------+--------------------------------------------------
 This ticket loosely specs the idea, and serves as an action item for
 creating an API by U.2 that will allow this system to work in the future
 when we add versions.

 '''The Background (quoted from HIG):'''

 "Most of us recognize the 'save early, save often' mantra; most of us have
 failed to live it and incurred the consequences. The laptops aim to
 eliminate constant concern for this type of technicality, making automatic
 and incremental backups and allowing the children to focus on the activity
 itself. These incremental backups will occur at regular time intervals,
 and activity events such as changes in scope, new participants, among
 others can trigger them as well. In order to cater to the needs of many
 types of editing environments, activities can also specify "keep-hints"
 which prompt the system to keep the current state in the Journal. For
 instance, a drawing activity may trigger a keep-hint before executing an
 'erase' operation immediately preceded by a 'select all'. Of course, a
 child herself may choose to invoke a keep-hint by selecting the "keep in
 journal" button, but adequate adoption of this new notion of keeping from
 activities should virtually eliminate need for this."

 '''The details:'''

 The core idea here is that we want to preserve data as much as possible,
 and we want to do this even when connectivity drops and activities crash.
 The way this should work, ideally, is that activities can make two kinds
 of calls to the Journal.  For lack of a better terminology, I'll refer to
 these as ''active'' and ''passive'' "keep"s.

  - Passive: The activity should create backups of its current state (auto-
 saves) periodically to prevent data loss in case of a crash.  It should
 pass this data (or at least the path to it) to the Journal so that the
 Journal can make use of it later.  A passive keep doesn't result directly
 in new Journal entries, or in any way affect the contents of the Journal.

  - Active: An active keep is a "keep-hint" as referred to in the HIG,
 which would happen when a) a kid presses the "Keep" button b) the activity
 wants to force a new version c) the activity stops.  In all of these
 cases, the activity should pass the data/path to the Journal and a new
 entry (or version thereof) should be created. Additionally, reference to
 the current passively kept data can be thrown away, as the latest copy is
 now stored. (Note that in the near term, (a) will actually create a new
 entry (copy), while (b) and (c) will overwrite the current copy.)

  - Implicit: The benefit of the passive keeps is that, if for any reason
 the activity cannot perform an active keep (due to a crash, etc.), the
 Journal can take over, creating a new Journal entry version with the most
 recent passively kept data.  Ideally, this data would be preserved such
 that, even in case of power failure, the Journal can locate any leftover
 passively kept data and create entries as needed the next time it
 launches. (Note that in the near term, this will overwrite the current
 copy.)

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