Shared revisions

From OLPC
Revision as of 20:42, 19 November 2008 by Sj (talk | contribs) (New page: There are a number of different ways to share the state of an activity with a group of collaborators / editors. One is an unordered set of actions, which don't depend on one another. Any...)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

There are a number of different ways to share the state of an activity with a group of collaborators / editors.

One is an unordered set of actions, which don't depend on one another. Any action can be undone independently of the others. (imagine a group of people adding bigts of colored light to a large prismatic collage; you can add or subtract light and color independent of all other lights/colors)

Another is a set of causal actions, which are partially ordered and do depend on one another. For instance a Write or Paint session, some of whose actions change actions that have come before.

There is also a punctuated equilibrium model which is fairly general...

punctuated equilibrium

Punctuated equilibrium supports a set of actions:

 sync
 undo to last sync
 soft-undo last action [of mine]
 soft-undo last action [of anyone's]
 save state
 fork
 soft-undo last action (of other) would be the last action before the sync, right?
 attempt merge [can happen while forked]
 push/suggest merge to others
<homunq> what is difference between merge and sync?
<_sj_> in between syncs, you have soft updates and attempted undo's
<_sj_> if it's obvious how to undo and there is nothing else that depends on the last action
<_sj_> you can undo it, whoever else did it; 
<_sj_> you can also try to undo your own action even if other changes hav eoccerred elsewhere, say if you are working in one part of a shared system and other changes are independent of it
<_sj_> (it = the part you are working on)
<_sj_> sync is basically a 'save state + push merge' where the merge seems automatic
<_sj_> you can also fork and make changes on your own, no longer accepting changes made by others, and later come back and attempt/suggest a merge to those being shared with
<_sj_> you need UI indicators and elements that lat you know when you are forked / out of sync
<_sj_> and when someone is pushing a sync
<_sj_> and that show you the expected diff b/t your current state and a suggested new state