A Change-Oriented Concurrency Model for Collaborative Applications

1
Palimpsest

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

2
IntroductionWhat do I Want to Say?

• Theres a better way!
• For what?
• and how?
• and why?

3
Overview

• Collaboration and editing
• Synchronization and change
• Palimpsest concepts
• Palimpsest Algorithms and System Architecture

4
CSCW

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

5
Collaborative Editing

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

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

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

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

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

10
Unifying (a)-synchrony

• Unification not a new idea
• Enables opportunism
• Requires different implementation strategies and
  models
• Prospero, Bayou, other systems address this

11
Reduce GuaranteesFocus on Operations

• Relaxed consistency
• Change oriented
• Replicated architectures
• Operational definitions

12
Specific problems

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

13
Standard Solutions

• Operational transformation
• Differencing merging
• Locking
• Ignoring
• 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

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

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)

17
What Kinds of Changes?

• A Taxonomy along 2 Axes
• Dynamism
• Scope

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

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

20
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
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

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?

23
Palimpsest Operations

• Insert
• Delete
• Dynamic Move
• Dynamic Copy
• Frozen operations are made from insert and delete

24
How to Track Offsets

• Dont!
• Represent positions in terms of the operations
  that create them
• Represent operations in terms of the addresses
  they affect

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

26
Insert and Delete
I1
I2
It was
hard.
D1
really
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

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
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

30
How to compare addresses
I1
I2
I4
I3
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 dont, order by the destinations of their
  leading changes

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)

33
Conflict types

• Simple conflicts (missing targets)
• Ordering conflicts (dynamic operations only)
• Data can be "captured"

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

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

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

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)

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

39
Support Issues Revisited

• Opportunism
• Synchronous vs. asynchronous work
• Undo
• Screen Consistency

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

41
Synchronous vs. asynchronous work

• Timing of change distribution doesnt matter
• Latency increases divergence between
  collaborators, but never impacts correctness

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

43
Screen Consistency

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

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

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