Talk:Version support for datastore/Proposal

Scratch area

Everything below isn't meant for public consumption, but just a reminder / place of reflection for me.

mtd

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.

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]

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

first part and second part of Roadmap mail.