148
in supporting both styles of work. The architecture allows for a wide variety of synchronous
and asynchronous policies by taking advantage of the change-oriented model to decouple
application operations from distribution and synchronization issues.
Requirement 3 advocates support for multiple and single-user undo. The model easily en-
compasses the description of very flexible and general undo support, and we saw algorithms
that enable undo (and re-do) to work efficiently, as well as an architecture to support it. The
special consistency problems with multi-user undo are actually obviated by the structure of
the model itself.
Requirement 4 advocates version management for fully general version graphs. Chapter 5
showed that such graphs are easily modeled in Palimpsest, including some forms of version
graph that are difficult or impossible for version-complete systems that are not also change-
complete.
Requirement 5 advocates the maintenance of hypertext links even in a multi-user, multi-
version editing context. The model directly supports this because the P-sequence address
structure enables makes persistent selection management as simple as storing the Palimpsest
addresses of the range in question. Palimpsest comparison facilities enable the fine-grained
tracking of persistent selections across updates.
Requirement 6 suggests that a wide variety of data structures should be supported. The
Palimpsest model provides only a sequence data type. This data type, however, is one of the
most powerful and general data types in common use, and one on top of which a variety of
structures can be layered.
Requirement 7 is a system requirement that an application should be able to control its
own data consistency parameters. The model can detect (and automatically resolve) certain
consistency problems. The architecture provides maintains the information required for ap-
plications to monitor operations and to signal application inconsistencies. Changes that
in supporting both styles of work. The architecture allows for a wide variety of synchronous
and asynchronous policies by taking advantage of the change-oriented model to decouple
application operations from distribution and synchronization issues.
Requirement 3 advocates support for multiple and single-user undo. The model easily en-
compasses the description of very flexible and general undo support, and we saw algorithms
that enable undo (and re-do) to work efficiently, as well as an architecture to support it. The
special consistency problems with multi-user undo are actually obviated by the structure of
the model itself.
Requirement 4 advocates version management for fully general version graphs. Chapter 5
showed that such graphs are easily modeled in Palimpsest, including some forms of version
graph that are difficult or impossible for version-complete systems that are not also change-
complete.
Requirement 5 advocates the maintenance of hypertext links even in a multi-user, multi-
version editing context. The model directly supports this because the P-sequence address
structure enables makes persistent selection management as simple as storing the Palimpsest
addresses of the range in question. Palimpsest comparison facilities enable the fine-grained
tracking of persistent selections across updates.
Requirement 6 suggests that a wide variety of data structures should be supported. The
Palimpsest model provides only a sequence data type. This data type, however, is one of the
most powerful and general data types in common use, and one on top of which a variety of
structures can be layered.
Requirement 7 is a system requirement that an application should be able to control its
own data consistency parameters. The model can detect (and automatically resolve) certain
consistency problems. The architecture provides maintains the information required for ap-
plications to monitor operations and to signal application inconsistencies. Changes that
