Figure 1 Version management in the group editor - during partition Figures 1 and 2 show an example with three users during and after a network partition: The initial state of the document was ‘x’. Then a network failure sep- arated Site 3 from Sites 1 and 2. In every partition an update was carried out (leading to state ‘y’ in one partition and to state ‘z’ in the other partition). After that update User 2 changed the ‘y’ to ‘p’ as private update (Fig. 1). Then the net- work failure that caused the partition disappeared and the sites exchanged their information. The conflict was recognized (branch in version trees) but the display did not change (Fig. 2). The authors have to resolve the conflict by merging the different versions later.
Related Figures (3)
![The se layers consist of separate processes that communicate. Aside from the modularization gains, a big advantage of this concept is that it is very easy to integrate standard document editing applications into the system as user interfaces. There are two possibilities: If you have access to the source code of the single user editor or if the editor is highly programmable you can replace the access layer of t d t a he edi GNU-] o not he edi ccess C hange tor by calls to the IRIs access layer. We used that approach to implement a FE MACS user interface with Elisp. If you do not have access to the source or want to change the standard application, you must implement a shell for tor that receives the document or a subtree of the document from the IRIs ayer. The shell presents it to the editor as a file and transfers the data in the d file back to the access layer after the standard editor has been terminated or whenever the temporary file was changed. We used that second approach to implement a text editor (e.g. VI, AXE) and a FRAMEMAKER user interface. Fig. 3. User view of the IRIS environment](https://figures.academia-assets.com/30665008/figure_003.jpg)
