143
tween loosely collaborating individuals. The architecture proposed here allows the pattern of
communication to be abstracted away and managed separately from many details of commu-
nication medium and protocol.
7.2 The application interface
The most basic interface between an application and a Palimpsest data store would be the
set of methods presented in Figure 7.2. That interface not only provides a lot of detail, but it
assumes that the application is building its displays directly from the Palimpsest data struc-
tures. While that is a valid option, in many situations it is not the most convenient option.
Nor is it necessarily the most efficient option. The reason is that most user interface toolkits
already have highly developed interactive text-editing modules. These modules are not al-
ways the mostfull-featured interactive editors available on a platform; generally specialized
tools like programming editors and word processing packages occupy this niche. Their use
usually provides a significant savings in application development time (because even bad
text-editors take a lot of work to write), and they often include specialized performance fea-
tures that may be hard to duplicate.
Finally, it is often desirable to integrate collaboration features into existing programs
that already have editing interfaces clearly defined. The case for extending existing applica-
tions rather than building new ones has been strongly advocated in the Open Hypermedia
systems community (Nürnberg, Leggett et al. 1998; Grønbæk and Trigg 1999 (forthcoming)).
The related notion of collaboration transparency (Lauwers and Lantz 1990)also has a long
history. The architecture presented here is not trying to solve the problem of providing
useful collaboration using unmodified applications. Indeed, collaboration support that allows
for divergence and provides methods to repair divergent states is probably incompatible with
the use of unmodified applications that are not also powerful programming environments
(like the Emacs editor).
tween loosely collaborating individuals. The architecture proposed here allows the pattern of
communication to be abstracted away and managed separately from many details of commu-
nication medium and protocol.
7.2 The application interface
The most basic interface between an application and a Palimpsest data store would be the
set of methods presented in Figure 7.2. That interface not only provides a lot of detail, but it
assumes that the application is building its displays directly from the Palimpsest data struc-
tures. While that is a valid option, in many situations it is not the most convenient option.
Nor is it necessarily the most efficient option. The reason is that most user interface toolkits
already have highly developed interactive text-editing modules. These modules are not al-
ways the mostfull-featured interactive editors available on a platform; generally specialized
tools like programming editors and word processing packages occupy this niche. Their use
usually provides a significant savings in application development time (because even bad
text-editors take a lot of work to write), and they often include specialized performance fea-
tures that may be hard to duplicate.
Finally, it is often desirable to integrate collaboration features into existing programs
that already have editing interfaces clearly defined. The case for extending existing applica-
tions rather than building new ones has been strongly advocated in the Open Hypermedia
systems community (Nürnberg, Leggett et al. 1998; Grønbæk and Trigg 1999 (forthcoming)).
The related notion of collaboration transparency (Lauwers and Lantz 1990)also has a long
history. The architecture presented here is not trying to solve the problem of providing
useful collaboration using unmodified applications. Indeed, collaboration support that allows
for divergence and provides methods to repair divergent states is probably incompatible with
the use of unmodified applications that are not also powerful programming environments
(like the Emacs editor).
