344
edits
Changes
Jump to navigation
Jump to search
Talk:Version support for datastore/Proposal (view source)
Revision as of 18:45, 15 April 2009
, 18:45, 15 April 2009copy some quotes from ML
== 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...
:* <nowiki>[</nowiki>storage/processing efficiency important<nowiki>]</nowiki>
;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.
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...
:* <nowiki>[</nowiki>storage/processing efficiency important<nowiki>]</nowiki>
;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.