2. Tuesday, April 27, 1999Palimpsest A Change-Oriented Concurrency Model for Collaborative Applications David G. Durand Boston University

3. Tuesday, April 27, 1999Palimpsest Introduction: What do I Want to Say? There’s a better way! For what? … and how? … and why?

4. Tuesday, April 27, 1999Palimpsest Overview Collaboration and editing Synchronization and change Palimpsest concepts Palimpsest Algorithms and System Architecture

5. Tuesday, April 27, 1999Palimpsest CSCW Computer Supported Cooperative Work A very particular kind of work Many relevant disciplines Still experimental  Long history  Some successes

6. Tuesday, April 27, 1999Palimpsest Collaborative Editing WYSIWIS / Screen Sharing  Consistency issues  Display Anomalies  User-Interface Anomalies All: user Support Issues  Opportunism  Synchronous vs. asynchronous work  Undo

7. Tuesday, April 27, 1999Palimpsest Opportunism Notion due to to Beck and Bellotti Based on observations of collaborating authors Explicit agreements were common …. and as commonly broken Progress is more important than consistency

8. Tuesday, April 27, 1999Palimpsest Synchronous vs. Asynchronous work. A useful if artificial distinction A major axis of collaboration typology Same Time / Different Time Often reflected in system design

9. Tuesday, April 27, 1999Palimpsest Problems: Asynchrony Locking is bad for human interface Without locking, changes may conflict Tracking states does not work well they diverge Tracking operations is better, but dependencies between operations make it difficult

10. Tuesday, April 27, 1999Palimpsest Problems: Synchrony Tracking states is even harder Just propagating updates can be confusing for users (Greenberg and Marwood '94) Real-time performance Locking is even less attractive Operational approaches on the upswing

11. Tuesday, April 27, 1999Palimpsest Unifying (a)-synchrony Unification not a new idea Enables opportunism Requires different implementation strategies and models Prospero, Bayou, other systems address this

12. Tuesday, April 27, 1999Palimpsest Reduce Guarantees Focus on Operations Relaxed consistency Change oriented Replicated architectures Operational definitions

13. Tuesday, April 27, 1999Palimpsest Specific problems Synchronous to Asynchronous transition Consistency of views Collaborative Undo Version Management (w/ Merging) Cross-version hypertext references Declarative model of consistency

14. Tuesday, April 27, 1999Palimpsest Standard Solutions Operational transformation Differencing + merging Locking Ignoring Palimpsest

15. Tuesday, April 27, 1999Palimpsest Palimpsest: A Data Model Palimpsest is operation-oriented Not committed to one update protocol Not committed to a user-interface model Not dependent on transport layer details Minimally committed to policy

16. Tuesday, April 27, 1999Palimpsest Why Use a Data Model? It is not tied to any one implementation Semantics are easier to define Data handling facilities can be re-used for many applications The data model provides a target for improved algorithms

17. Tuesday, April 27, 1999Palimpsest Type: Sequence Targeted to documents, but not solely Operations: indexed access, insert, delete, move, copy. A building block for other types:  Tables (cross-product of sequences)  Records (fixed length sequences)

18. Tuesday, April 27, 1999Palimpsest What Kinds of Changes? A Taxonomy along 2 Axes Dynamism Scope

19. Tuesday, April 27, 1999Palimpsest The static/dynamic axis Static operations always commute Static operations depend on locations but not history Dynamic operations enforce constraints Dynamic operations inherently depend on other changes to some extent

20. Tuesday, April 27, 1999Palimpsest Operation Scope How much data does the operation actually affect Could simply affect the data in the operation (e.g. insert) Could depend on the data targeted, but always have a single consistent effect Could depend on the actual contents of the data

21. Tuesday, April 27, 1999Palimpsest What Kinds of Changes Static Insert, Delete Frozen Move,Copy, Transpose Frozen Sort, Filter Frozen Global Change, Frozen Spelling Correction Dynamic Insert, Delete Move, Clone/Copy, Transpose Sort, Filter (arbitrary local constraints) Global Change, Spelling Validation (arbitrary global constraints) Independent Permutational Content-dependent Limited Scope Global Scope

22. Tuesday, April 27, 1999Palimpsest Edit Logs Messy because they have unbounded temporal dependencies  Consider positions in a sequence being edited These reflect data dependencies  Insertions into a sequence have a context

23. Tuesday, April 27, 1999Palimpsest What breaks? Offsets Change  Sticky pointers  Dynamic pointers Dix has also noted that offsets are a key part of the problem Why not replace temporal tracking by tracking of data dependencies?

24. Tuesday, April 27, 1999Palimpsest Palimpsest Operations Insert Delete Dynamic Move Dynamic Copy Frozen operations are made from insert and delete

25. Tuesday, April 27, 1999Palimpsest How to Track Offsets Don’t! Represent positions in terms of the operations that create them Represent operations in terms of the addresses they affect

26. Tuesday, April 27, 1999Palimpsest Sequences and Addressing Simple locations addressed by a pair (changeID, offset) Suffices for insert/delete and all static operations Problems of operational transformation are sidestepped and transformed

27. Tuesday, April 27, 1999Palimpsest Insert and Delete I1 I2 It washard. really D1

28. Tuesday, April 27, 1999Palimpsest Dynamic Addressing Dynamic operations need to create new addresses without freezing Deletion and move control visibility Move, copy, and insert make new addresses Dynamic addresses reflect a source and a sequence of dynamic applications

29. Tuesday, April 27, 1999Palimpsest A B C D E A B C F Move and Copy A B C D E F M1C1 I1 A B C D E A B C F I1.0, I1.1 M1.I1.0, M1.I1.1 I1.0, I1.1 C1.I1.0, C1.I1.1

30. Tuesday, April 27, 1999Palimpsest How to compare addresses Insertions are the core, within an insertion all its positions are ordered To compare two insertions, find greatest lower bound, and trace back to that position

31. Tuesday, April 27, 1999Palimpsest How to compare addresses I3 I2 I1 I4

32. Tuesday, April 27, 1999Palimpsest Move / Copy Comparison Basic fact: move and copy duplicate addresses elsewhere Two cases:  If addresses share a prefix, truncate and try again  If they don’t, order by the destinations of their leading changes

33. Tuesday, April 27, 1999Palimpsest Advantages and Problems Free combinations of changes often possible Dependencies easy to detect Undo works even in diverging histories Not all combinations work so well: Some change ordering is unavoidable (but arbitrary)

34. Tuesday, April 27, 1999Palimpsest Conflict types Simple conflicts (missing targets) Ordering conflicts (dynamic operations only) Data can be "captured"

35. Tuesday, April 27, 1999Palimpsest Advantages of Change- orientation All change information is relative to other changes Minimal dependencies exist on order of application of changes Changes are immutable (this is a nice property for replication/transport) Merge and multi-user undo become trivial Conflict detection is easy

36. Tuesday, April 27, 1999Palimpsest Other problems solved Version management A version is now a set of changes Persistent addressing for hypertext This is really a consequence of version management. This is a declarative model based on how to interpret a set of changes

37. Tuesday, April 27, 1999Palimpsest Implementing Palimpsest Local interpretation of change sets is important  basic algorithms exist Distribution issues are as simple as one can hope for  Transport independence is easy  Application independence is pretty easy  Interactive response is a matter of quick delivery

38. Tuesday, April 27, 1999Palimpsest Palimpsest System Structure Layered managers (providing special objects) Local Repository /Local communication connections Arena manager (stores changes) Palimpsest manager (implements application view of objects described by changes)

39. Tuesday, April 27, 1999Palimpsest Palimpsest Architecture Replication and control are reduced to data distribution Change processing is a database problem Epidemic protocols are one of many Missing changes can always be requested

40. Tuesday, April 27, 1999Palimpsest Support Issues Revisited Opportunism Synchronous vs. asynchronous work Undo Screen Consistency

41. Tuesday, April 27, 1999Palimpsest Opportunism Lack of locking is good Ability to combine changes Ability to support merge is good Communication independence is important Need to merge is significant coordination work

42. Tuesday, April 27, 1999Palimpsest Synchronous vs. asynchronous work Timing of change distribution doesn’t matter Latency increases divergence between collaborators, but never impacts correctness

43. Tuesday, April 27, 1999Palimpsest Undo Just remove a change to undo it Changes are as independent as can be managed under fairly liberal assumptions Location of change creation does not matter Creator of change does not matter

44. Tuesday, April 27, 1999Palimpsest Screen Consistency Palimpsest provides no particular help, perhaps even some harm Real-time collaborations are no worse, just not any better

45. Tuesday, April 27, 1999Palimpsest Hypertext Anchors and Markup Structures The Palimpsest address space is extremely useful Link anchor tracking (a hard problem) is solved as a side effect External markup structures can be similarly laid on top of Palimpsest Obviously markup fits inside a sequence as well

46. Tuesday, April 27, 1999Palimpsest Summary Palimpsest treats consistency purely in terms of atomic operations Shifting perspective to changes simplifies system structure More importantly, it unifies several problems, while solving them neatly