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

From Sugar Labs
Jump to navigation Jump to search
(update link for Google Doc)
 
(4 intermediate revisions by 2 users not shown)
Line 7: Line 7:
 
[[Image:journal-version-mockup-4.png|800px|thumb|left|Third mockup: combo box with Favourite stars (closed)]]
 
[[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)]]
 
[[Image:journal-version-mockup-5.png|800px|thumb|left|Third mockup: combo box with Favourite stars (open)]]
−
 
+
<br clear>
 
== Scratch area ==
 
== Scratch area ==
  
Line 24: 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.
 
: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.
 +
 +
;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 ===
 
=== IRC notes ===
Line 73: Line 82:
 
= Datastore feature requests =
 
= Datastore feature requests =
  
−
=== Features that could benefit Library activity ===
+
* [[Development_Team/Release/Roadmap/0.86#Datastore_features_that_could_benefit_Library]]
−
 
 
−
These features can benefit [[Activities/Library]] activity. At present(for 0.82/0.84) Library uses "rich" datastore client which fetches all Journal objects to make short list of objects(by collapsing all versions to one item), moreover it has to unzip .xo bundles to get ''bundle_id'' value. So its not good.
 
−
 
 
−
With all these features implemented Library can use "thin" datastore client and not fetch all objects, just make proper request for datasotre.find() to get sorted and collapsed objects by portions (by using offset/limit find() arguments).
 
−
 
 
−
====== Provide object id field ======
 
−
 
 
−
That should mean that any datastore object should have "object id":
 
−
* ''activity_id'' for objects that were generated by activities (already implemented)
 
−
* ''bundle_id'' for .xo bundles in the Journal
 
−
* ''uid'' for other objecets (already implemented)
 
−
 
 
−
====== History of collapsed object ======
 
−
 
 
−
Let datastore clients browse history of collapsed objects:
 
−
* for ''activity_id'' objects - sort by timestamp (already impelemented)
 
−
* for ''bundle_id'' objects - sort by ''activity_version''(or so) field
 
−
 
 
−
====== Sort find()'s resultset ======
 
−
 
 
−
Let datastore clients sort objects by any field(not only predefined like uid, activity_id etc).
 

Latest revision as of 01:22, 6 December 2010

UI mockups

First mockup: previous and next buttons
Second mockup: combo box (closed)
Second mockup: combo box (open)
Third mockup: combo box with Favourite stars (closed)
Third mockup: combo box with Favourite stars (open)


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.
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. [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

Wiki links

Datastore feature requests

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Talk:Version_support_for_datastore/Proposal&oldid=60003"