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

Retrieved from "https://wiki.sugarlabs.org/go/Talk:Version_support_for_datastore/Proposal"

Return to "Version support for datastore/Proposal" page.

@@ Line 1: / Line 1: @@
+== 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 ==
@@ Line 15: / Line 24: @@
 :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]]