View source for Talk:Version support for datastore/Proposal

== UI mockups ==
[[Image:journal-version-mockup-1.png|800px|thumb|left|First mockup: previous and next buttons]]

[[Image:journal-version-mockup-2.png|800px|thumb|left|Second mockup: combo box (closed)]]
[[Image:journal-version-mockup-3.png|800px|thumb|left|Second mockup: combo box (open)]]

[[Image:journal-version-mockup-4.png|800px|thumb|left|Third mockup: combo box with Favourite stars (closed)]]
[[Image:journal-version-mockup-5.png|800px|thumb|left|Third mockup: combo box with Favourite stars (open)]]
<br clear>
== 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.

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

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. <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]
:"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:
:<nowiki>[</nowiki>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:
:<nowiki>[</nowiki>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
:<nowiki>[</nowiki>actions view out of scope]
:<nowiki>[</nowiki>multiversion XIP support similar to tla: hardlinked/sparse revision library + working copy hardlinking from revision library]

;homunq:
:<nowiki>[</nowiki>evaluate bazaar etc. as backend] -- SS: potential conflict with XIP - though git might be fine
:<nowiki>[</nowiki>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.
:<nowiki>[</nowiki>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 ===

* [http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00004.html first part] and
* [http://mail.gnome.org/archives/desktop-devel-list/2009-April/msg00005.html second part] of Roadmap mail.
* [http://live.gnome.org/GnomeZeitgeist GNOME Zeitgeist]

=== Wiki links ===
* [[Design Team/Designs/Journal|Journal design mockups]]
* [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded]

= Datastore feature requests =

* [[Development_Team/Release/Roadmap/0.86#Datastore_features_that_could_benefit_Library]]