Tuesday, April 27, 1999 Palimpsest
PalimpsestA Change-Oriented Concurrency
Model for Collaborative Applications
David G. Durand
Boston University
Tuesday, April 27, 1999 Palimpsest
Introduction:What do I Want to Say?
There’s a better way!
For what?
… and how?
… and why?
Tuesday, April 27, 1999 Palimpsest
Overview
Collaboration and editing
Synchronization and change
Palimpsest concepts
Palimpsest Algorithms and System Architecture
Tuesday, April 27, 1999 Palimpsest
CSCW
Computer Supported Cooperative Work
A very particular kind of work
Many relevant disciplines
Still experimental Long history Some successes
Tuesday, April 27, 1999 Palimpsest
Collaborative Editing
WYSIWIS / Screen Sharing Consistency issues
Display Anomalies User-Interface Anomalies
All: user Support Issues Opportunism Synchronous vs. asynchronous work Undo
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Synchronous vs. Asynchronous work.
A useful if artificial distinction
A major axis of collaboration typology
Same Time / Different Time
Often reflected in system design
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Unifying (a)-synchrony
Unification not a new idea
Enables opportunism
Requires different implementation strategies and models
Prospero, Bayou, other systems address this
Tuesday, April 27, 1999 Palimpsest
Reduce GuaranteesFocus on Operations
Relaxed consistency
Change oriented
Replicated architectures
Operational definitions
Tuesday, April 27, 1999 Palimpsest
Specific problems
Synchronous to Asynchronous transition
Consistency of views
Collaborative Undo
Version Management (w/ Merging)
Cross-version hypertext references
Declarative model of consistency
Tuesday, April 27, 1999 Palimpsest
Standard Solutions
Operational transformation
Differencing + merging
Locking
Ignoring
Palimpsest
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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)
Tuesday, April 27, 1999 Palimpsest
What Kinds of Changes?
A Taxonomy along 2 Axes
Dynamism
Scope
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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?
Tuesday, April 27, 1999 Palimpsest
Palimpsest Operations
Insert
Delete
Dynamic Move
Dynamic Copy
Frozen operations are made from insert and delete
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Insert and Delete
I1
I2
It was hard.
really
D1
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
A B C D E A B C F
Move and Copy
A B C D E F A B C D E F
M1 C1
I1 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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
How to compare addresses
I3
I2
I1
I4
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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)
Tuesday, April 27, 1999 Palimpsest
Conflict types
Simple conflicts (missing targets)
Ordering conflicts (dynamic operations only)
Data can be "captured"
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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)
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Support Issues Revisited
Opportunism
Synchronous vs. asynchronous work
Undo
Screen Consistency
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Synchronous vs. asynchronous work
Timing of change distribution doesn’t matter
Latency increases divergence between collaborators, but never impacts correctness
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
Screen Consistency
Palimpsest provides no particular help, perhaps even some harm
Real-time collaborations are no worse, just not any better
Tuesday, April 27, 1999 Palimpsest
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
Tuesday, April 27, 1999 Palimpsest
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