144
For these reasons, the simplest interface to a Palimpsest store, and possibly the best
performing one, is an interface that will facilitate the management of an independently
maintained screen buffer. Generally, it is easy to get access to fine-grained editing events
from many applications, and most “ready-made” text widgets.
The two prototype VTML editors that I have built followed this strategy with some suc-
cess. The interface to the back-end process (whether direct or via HTTP) operated in terms of
character offsets in the display buffer. The editing event information required to drive this
process was relatively easily accessible in both environments (Java text editing and the
Macintosh OS).
insert(version, dest, string)
delete(version, start, end)
move(version, start, end, dest)
copy(version, start, end, dest)
registerNotifier(version, notifier)
Notifer.insert(version, dest, string)
Notifer.delete(version, start, end)
ChangeList getChanges()
undo(Change change)
redo(Change change)
version getVersionHandle()
Buffer getContents(version)
F F F F iii ig g g gu u u ur r r re e e e 7777....3333:::: FFFFuuuunnnnccccttttiiiioooonnnnssss ffffoooorrrr mmmmaaaannnnaaaaggggiiiinnnngggg aaaa ppppaaaarrrraaaalllllllleeeellll bbbbuuuuffffffffeeeerrrr
The functions in Figure 7.3 all take a version parameter: this is a unique token repre-
senting a specific state of the editor buffer. The application is responsible for passing editing
events to the Palimpsest implementation using the first four methods. When external
changes arrive from collaborators, the adjustments to the state of the document are pre-
sented to the application’s notifier in the form of insertion and deletion events. The same
mechanism is used to reflect buffer state changes to the application when operations such as
undo or redo are executed and cause the buffer state to change. The version and change
For these reasons, the simplest interface to a Palimpsest store, and possibly the best
performing one, is an interface that will facilitate the management of an independently
maintained screen buffer. Generally, it is easy to get access to fine-grained editing events
from many applications, and most “ready-made” text widgets.
The two prototype VTML editors that I have built followed this strategy with some suc-
cess. The interface to the back-end process (whether direct or via HTTP) operated in terms of
character offsets in the display buffer. The editing event information required to drive this
process was relatively easily accessible in both environments (Java text editing and the
Macintosh OS).
insert(version, dest, string)
delete(version, start, end)
move(version, start, end, dest)
copy(version, start, end, dest)
registerNotifier(version, notifier)
Notifer.insert(version, dest, string)
Notifer.delete(version, start, end)
ChangeList getChanges()
undo(Change change)
redo(Change change)
version getVersionHandle()
Buffer getContents(version)
F F F F iii ig g g gu u u ur r r re e e e 7777....3333:::: FFFFuuuunnnnccccttttiiiioooonnnnssss ffffoooorrrr mmmmaaaannnnaaaaggggiiiinnnngggg aaaa ppppaaaarrrraaaalllllllleeeellll bbbbuuuuffffffffeeeerrrr
The functions in Figure 7.3 all take a version parameter: this is a unique token repre-
senting a specific state of the editor buffer. The application is responsible for passing editing
events to the Palimpsest implementation using the first four methods. When external
changes arrive from collaborators, the adjustments to the state of the document are pre-
sented to the application’s notifier in the form of insertion and deletion events. The same
mechanism is used to reflect buffer state changes to the application when operations such as
undo or redo are executed and cause the buffer state to change. The version and change
