From AbiWiki

Revision as of 06:30, 24 November 2010

<!--Modify this as appropriate, especially if its not an FAQ--> <!--Aside: using H2 and H3 is a trick for old TWikis to keep headings out of the ToC--> <!--Delete this line and those above, and anything else that is not needed when you create the page, leave the ToC commented out if you dont use it-->

<H2>Mark Gilberts ideas on AbiCollab</H2>

In my opinion [MG] we need more robust conflict presentation, resolution, and synchronization approaches. This means many things which I have written about in more detail elsewhere, but as a response to the above Id like to point out that part of this is hierarchical exchange preferences (a very useful feature once AbiCollab is productively usable) affecting in-session nonconcurrent conflict resolution and part is out-session nonconcurrent conflict resolution (concurrent conflicts are best resolved by decoration and notation). In-session is obviously handled using revisions. Out-session, I hypothesize, is best handled using delta component dependancy classification whereby we use much of our EXISTING document history code* to establish a context for the revisional diffs presented of conflicting changes (that were made out of session and therefore, out of sync). This is a hybrid of the in-session prioritized adjustment from in-session CR overrides which we use for non-conflicting syncronization, and the concurrency conflict approach which we use in a Heisenberg scenario that any and all unsyncronized changes occuring out of session effectively occurred simultaneously. Sprinkled on top to make all this run smoothly is something unique to out-session changes - context propogation. Why? Even unsyncronized nonconcurrent in-session changes have effectively guaranteed context equivalency which means that the entirety of the material we need to account for is contained within the CR itself. Nonconcurrented unsyncronized in-session changes still have an effetively guaranteed context-equivalency, hence while context would theoretically need to be checked, the fact that syncronization is live and not on-demand essentially resolves that to a constant truth. Out-of-session, though, is a completely different matter. All context assumptions go out the window because heaven only knows how many and what manner of revisions occurred since the last syncronization. Therefore we take advantage of our history code to differentiate the compatible changes from the conflicting revisions, and then only diff those. Session-independence makes AbiCollab immensely more useful, and this makes session-independence possible. Finally, it affords us an opportunity down the road to take advantage of some of the same techniques I use for predictive conflict classification algorithms, such as utilizing a relational classifying parser to automatically resolve equivalencies according to the documents preferences (always choose the shortest/simplest/clearest checkbox on action). If its still not clear why Im making this so complicated, imagine opening your document and being prompted "There have been 1,274 revisions since the last syncronization. Click Next to start reviewing them" or having a document 3 times as long due to concurrency prompts when in fact you only care about 3 or 4 of them. Anyway, these algorithms and the decoration framework (largely pulled from existing extra-body visual code with some new stuff) to communicate their functions to the user is what Im currently working on (20060503).

• (hat-tip to Tomas - I didnt understand how useful this was when you first started talking about it)

<!-- <H3>Contents</H3>

-->

Contributors

• Main.MartinSevior - 02 Jan 2007