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

Tuesday, April 27, 1999 Palimpsest

PalimpsestA Change-Oriented Concurrency

Model for Collaborative Applications

David G. Durand

Boston University


Introduction:What do I Want to Say?

There’s a better way!

For what?

… and how?

… and why?


Overview

Collaboration and editing

Synchronization and change

Palimpsest concepts

Palimpsest Algorithms and System Architecture


CSCW

Computer Supported Cooperative Work

A very particular kind of work

Many relevant disciplines

Still experimental Long history Some successes


Collaborative Editing

WYSIWIS / Screen Sharing Consistency issues

Display Anomalies User-Interface Anomalies

All: user Support Issues Opportunism Synchronous vs. asynchronous work Undo


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


Synchronous vs. Asynchronous work.

A useful if artificial distinction

A major axis of collaboration typology

Same Time / Different Time

Often reflected in system design


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


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


Unifying (a)-synchrony

Unification not a new idea

Enables opportunism

Requires different implementation strategies and models

Prospero, Bayou, other systems address this


Reduce GuaranteesFocus on Operations

Relaxed consistency

Change oriented

Replicated architectures

Operational definitions


Specific problems

Synchronous to Asynchronous transition

Consistency of views

Collaborative Undo

Version Management (w/ Merging)

Cross-version hypertext references

Declarative model of consistency


Standard Solutions

Operational transformation

Differencing + merging

Locking

Ignoring

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


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


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)


What Kinds of Changes?

A Taxonomy along 2 Axes

Dynamism

Scope


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


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


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


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


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 Operations

Insert

Delete

Dynamic Move

Dynamic Copy

Frozen operations are made from insert and delete


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


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


Insert and Delete

I1

I2

It was hard.

really

D1


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


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


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


How to compare addresses

I3

I2

I1

I4


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


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)


Conflict types

Simple conflicts (missing targets)

Ordering conflicts (dynamic operations only)

Data can be "captured"


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


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


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


Support Issues Revisited

Opportunism

Synchronous vs. asynchronous work

Undo

Screen Consistency


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


Synchronous vs. asynchronous work

Timing of change distribution doesn’t matter

Latency increases divergence between collaborators, but never impacts correctness


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


Screen Consistency

Palimpsest provides no particular help, perhaps even some harm

Real-time collaborations are no worse, just not any better


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


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

Documents

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