Talk:Version support for datastore/Proposal

UI mockups






Scratch area
Everything below isn't meant for public consumption, but just a reminder / place of reflection for me.

ML notes

 * mtd:
 * it has to be simple and natural to prune old versions and documents
 * ... and to display the disk usage of docs and their versions!
 * it has to interop well with the FS underneath
 * it has to interop with the XS-based backups...
 * [ storage/processing efficiency important ]


 * Eben:
 * Basically, all versions of a document would appear within the list view timeline. Their order within the list would be determined by their timestamp. If I work on 3 iterative versions of a document, then go back to the second version and make changes, I get a new 4th version which appears as the most recent item in the Journal. It doesn't matter (at least here) that I technically have a branch at version 2, which has children 3 and 4. What matters in the Journal perspective is that I worked on version 4 most recently. The tree is flattened into a list in the time dimension.
 * This is also the reason that the latest Journal designs split the UI into "action" and "object" views. The action view would be a temporal history of everything you've done (with each version through time). The object view would represent each object only once, by it's most recent version, thus providing a much shorter list.

This thread, http://www.mail-archive.com/sugar-devel@lists.sugarlabs.org/msg06008.html, consolidated in context,
 * Eben & Tomeu:

https://docs.google.com/Doc?docid=0AbFyRSVE0dmOZGQ5emZjOTZfMzBoeG1qMjhqbg&hl=en

sugarlabs.org Google Docs original:

https://docs.google.com/Doc?docid=0AUl2E5uTm959ZGd3N3FucXdfMWhzbjVjeGht&hl=en

IRC notes

 * bemasc:
 * Activities are stateless functions. That is, an Activity has no intrinsic state; if you start it blank, it's the same every time.
 * All state lives in the Datastore. When you launch an Activity with a Journal entry as input, it produces output that goes back in the Journal.
 * Consider what happens when a user "resumes" an entry twice, maybe even with two different activities. What should happen?
 * It seems pretty clear to me that the result should be two entries, representing the output of each of these activities. [ new branch, with same or different name]
 * [ example for whole-tree activity state: wine activity]
 * [ xdelta for binary diffs]
 * [ in-place execution of activities from datastore]
 * "Running an activity" is a special system-level action available on objects of type "Activity". It specifically means "Executing the code in activity object X with a null input". The other action is "Open with {some activity}".
 * another possibility is to ignore branches, and have each leaf ("head") simply show all of its ancestors as a list.
 * The Actions view shows "a temporal view of what I did", and the Objects view shows "what I have".


 * tomeu:
 * [ opportunistic hardlinking using mtime+checksum]
 * all activities should be able to read all journal instances written by past versions, but we cannot expect it will be that way


 * silbe:
 * [ filenames are just metadata]
 * what about resuming old entries then? does it "run" the activity version it was created in?
 * we could filter "temporally near" versions in the default view.
 * instead of / in addition to the version tree view, we could have a filter that shows only the "related" (i.e. member of same version tree) documents in the regular Journal view
 * [ actions view out of scope]
 * [ multiversion XIP support similar to tla: hardlinked/sparse revision library + working copy hardlinking from revision library]


 * homunq:
 * [ evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine
 * [ run activities directly from zip file]
 * In the main journal list, you can have old versions in the palette, much like the new resume-by-default behaviour in current home view. In journal details, I guess you could have "previous" and "next" buttons as the simple first pass, I'd like a list of versions even better.
 * I'd argue that showing separate versions separately in journal list will never be the right thing. I'd rather have ALL old versions totally invisible in journal list (only accessible through "prev/next version" buttons in detail view) than have anything.
 * [ in response to current Journal being temporal view, so intermediate versions should be there] OK, but they should be grouped, and collapsed by default, to show just head
 * I think the simplest, usable prototype would be what I said: just head in list, prev/next buttons in details.
 * for now, I'd accept tags as either by-version or global, but mutable and not versioned themselves
 * it's really a question of UIs and workflows, and having the prototype will help us actually test some workflows and get a more-informed conversation

Gnome work

 * first part and
 * second part of Roadmap mail.
 * GNOME Zeitgeist

Wiki links

 * Journal design mockups
 * Journal reloaded

= Datastore feature requests =


 * Development_Team/Release/Roadmap/0.86