Difference between revisions of "Talk:Version support for datastore/Proposal"

From Sugar Labs
Jump to navigation Jump to search
(copy some quotes from ML)
 
(add some IRC notes)
Line 15: Line 15:
 
: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.
 
: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 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.
 +
 +
=== 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. <nowiki>[</nowiki>new branch, with same or different name]
 +
:<nowiki>[</nowiki>example for whole-tree activity state: wine activity]
 +
:<nowiki>[</nowiki>xdelta for binary diffs]
 +
:<nowiki>[</nowiki>in-place execution of activities from datastore]
 +
 +
;tomeu:
 +
:<nowiki>[</nowiki>opportunistic hardlinking using mtime+checksum]
 +
 +
;silbe:
 +
:<nowiki>[</nowiki>filenames are just metadata]
 +
 +
;homunq:
 +
:<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine

Revision as of 05:28, 16 April 2009

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.

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]
tomeu
[opportunistic hardlinking using mtime+checksum]
silbe
[filenames are just metadata]
homunq
[evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine
Retrieved from "https://wiki.sugarlabs.org/index.php?title=Talk:Version_support_for_datastore/Proposal&oldid=27523"