107
base, so that links can be updated as their destinations themselves are updated. The WWW
simply allows links to go bad, and does not provide fine-grained link anchors and anchor
tracking at any level.
Version management has been one traditional approach to this problem, as discussed, e.g.
by Hicks and Campbell. However, version-complete systems only allow retrieval of the par-
ticular past state when a link was made. Without fine-grained tracking of the regions and
the changes that affect them, the current state of link anchors is unavailable, as is its status
in other significant versions. The RHYTHM system (Maioli, Sola et al. 1994), and Nelson’s
proposal for Xanadu (Nelson 1987) both supplement version management systems with fine-
grained tracking operations to allow updated views of link anchors. Palimpsest follows this
general approach, by keeping editing histories and providing persistent pointers into evolv-
ing objects.
The idea of a global change set is relevant in a distributed system as well. It can be useful
to think of the union of the change sets at all collaborating sites as representing the global
history of an entire data structure. This global change set may well never be present on any
single system. Many collaborators will have changes in their local histories that were imme-
diately undone, and that may never be transmitted as part of any version of the shared data.
In an online editing system, any communication strategy that ensures the eventual conver-
gence of all collaborators to that global change set will also ensure that they all have identi-
cal views of the data.
5.3 Undoing in Palimpsest
The problem of (collaborative) undo is discussed in Section 1.6. Change orientation makes
it possible to manipulate changes individually, and Palimpsest specifies the effect that re-
moving a particular change from a P-sequence will have on its state, regardless of its history.
Changes can be removed from change sets as well as added, and the ability to do this with-
base, so that links can be updated as their destinations themselves are updated. The WWW
simply allows links to go bad, and does not provide fine-grained link anchors and anchor
tracking at any level.
Version management has been one traditional approach to this problem, as discussed, e.g.
by Hicks and Campbell. However, version-complete systems only allow retrieval of the par-
ticular past state when a link was made. Without fine-grained tracking of the regions and
the changes that affect them, the current state of link anchors is unavailable, as is its status
in other significant versions. The RHYTHM system (Maioli, Sola et al. 1994), and Nelson’s
proposal for Xanadu (Nelson 1987) both supplement version management systems with fine-
grained tracking operations to allow updated views of link anchors. Palimpsest follows this
general approach, by keeping editing histories and providing persistent pointers into evolv-
ing objects.
The idea of a global change set is relevant in a distributed system as well. It can be useful
to think of the union of the change sets at all collaborating sites as representing the global
history of an entire data structure. This global change set may well never be present on any
single system. Many collaborators will have changes in their local histories that were imme-
diately undone, and that may never be transmitted as part of any version of the shared data.
In an online editing system, any communication strategy that ensures the eventual conver-
gence of all collaborators to that global change set will also ensure that they all have identi-
cal views of the data.
5.3 Undoing in Palimpsest
The problem of (collaborative) undo is discussed in Section 1.6. Change orientation makes
it possible to manipulate changes individually, and Palimpsest specifies the effect that re-
moving a particular change from a P-sequence will have on its state, regardless of its history.
Changes can be removed from change sets as well as added, and the ability to do this with-
