Palimpsest: A Change-Oriented Concurrency Model for Collaborative Applications

1. Palimpsest A Change-Oriented Concurrency Model for Collaborative Applications David G. Durand Boston University Palimpsest

2. Introduction:What do I Want to Say? • There’s a better way! • For what? • … and how? • … and why? Palimpsest

3. Overview • Collaboration and editing • Synchronization and change • Palimpsest concepts • Palimpsest Algorithms and System Architecture Palimpsest

4. CSCW • Computer Supported Cooperative Work • A very particular kind of work • Many relevant disciplines • Still experimental • Long history • Some successes Palimpsest

5. Collaborative Editing • WYSIWIS / Screen Sharing • Consistency issues • Display Anomalies • User-Interface Anomalies • All: user Support Issues • Opportunism • Synchronous vs. asynchronous work • Undo Palimpsest

6. 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 Palimpsest

7. Synchronous vs. Asynchronous work. • A useful if artificial distinction • A major axis of collaboration typology • Same Time / Different Time • Often reflected in system design Palimpsest

8. 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 Palimpsest

9. 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 Palimpsest

10. Unifying (a)-synchrony • Unification not a new idea • Enables opportunism • Requires different implementation strategies and models • Prospero, Bayou, other systems address this Palimpsest

11. Reduce GuaranteesFocus on Operations • Relaxed consistency • Change oriented • Replicated architectures • Operational definitions Palimpsest

12. Specific problems • Synchronous to Asynchronous transition • Consistency of views • Collaborative Undo • Version Management (w/ Merging) • Cross-version hypertext references • Declarative model of consistency Palimpsest

13. Standard Solutions • Operational transformation • Differencing + merging • Locking • Ignoring • Palimpsest Palimpsest

14. 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 Palimpsest

15. 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 Palimpsest

16. 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) Palimpsest

17. What Kinds of Changes? • A Taxonomy along 2 Axes • Dynamism • Scope Palimpsest

18. 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 Palimpsest

19. 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 Palimpsest

20. 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) What Kinds of Changes Independent Permutational Content-dependent Limited Scope Global Scope Palimpsest

21. 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 Palimpsest

22. 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? Palimpsest

23. Palimpsest Operations • Insert • Delete • Dynamic Move • Dynamic Copy • Frozen operations are made from insert and delete Palimpsest

24. 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 Palimpsest

25. 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 Palimpsest

26. Insert and Delete I1 It was I2 hard. D1 really Palimpsest

27. 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 Palimpsest

28. Move and Copy I1 I1 A B C D E F A B C D E F M1 C1 A B C D E A B C F A B C D E A B C F I1.0, I1.1 I1.0, I1.1 M1.I1.0, M1.I1.1 C1.I1.0, C1.I1.1 Palimpsest

29. 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 Palimpsest

30. How to compare addresses I1 I2 I4 I3 Palimpsest

31. 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 Palimpsest

32. 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) Palimpsest

33. Conflict types • Simple conflicts (missing targets) • Ordering conflicts (dynamic operations only) • Data can be "captured" Palimpsest

34. 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 Palimpsest

35. 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 Palimpsest

36. 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 Palimpsest

37. 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) Palimpsest

38. 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 Palimpsest

39. Support Issues Revisited • Opportunism • Synchronous vs. asynchronous work • Undo • Screen Consistency Palimpsest

40. 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 Palimpsest

41. Synchronous vs. asynchronous work • Timing of change distribution doesn’t matter • Latency increases divergence between collaborators, but never impacts correctness Palimpsest

42. 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 Palimpsest

43. Screen Consistency • Palimpsest provides no particular help, perhaps even some harm • Real-time collaborations are no worse, just not any better Palimpsest

44. 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 Palimpsest

45. 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 Palimpsest