![]() |
![]() |
The application protocol defined and documented here is that controlling the reconciliation of different modifications made to the same document by separate authors. When a given document is checked out for editing by several authors at the same time, a protocol is required to reconciliate their modifications into a single, coherent document at the end. With the help of the document manager, the reconciliation protocol coordinates: the author(s) who are editing existing documents, the edited document itself and the reconciliation logic. This protocol governs the reconciliation of those documents separately edited by different authors and not those edited in the collaborative environment. There are three distinct cases that the protocol handles:
The situation when only one author edits a document at any time is by far the simplest. There are no complications from potentially conflicting changes which need to be reconciled. The author submits a request to the document manager to save the document. The document manager requests the Document-User tracking module to check whether any other person is working on the document concurrently. The Document-User tracker does an internal check, determining how many copies of the document have been issued at that time for editing, and communicates that only one copy of that document is out. The document manager in this case requests the DBMS to save the document as the latest revision. The DBMS, on completing the task, informs the manager that the document has been saved (thus creating another document object instance). The document manager, in turn, informs the author that his/her request has been completed and that the document has been saved.
Cases 2 and 3 of the protocol deal with scenarios where more than one author is working on a document concurrently. Therefore, this information and the protocol diagram below is the same for both cases. The latter part of each case will be given further below. When an author (say "author 1") requests the document manager to save his/her modified document, the manager (on checking with the Document-User tracker) informs "author 1" that other users ("author 2" and maybe more) are simultaneously working on the document. It also indicates to "author 1" that the document has been saved as version "X.a". When author 2 submits their modifications to the document manager, a similar check is done and an appropriate message displayed. When all authors who had been concurrently working on the document have submitted their changes, the document manager triggers the reconciliation logic, which checks versions "X .a", "X.b", ..."X.z" for new changes. Depending on whether these changes conflict, we have an example of either Case 2 (no conflicts) or Case 3 (conflicts). See below for the continuation of these scenarios.
If the reconciliation logic indicates that each author's changes are on different portions of the document, the document manager instructs the reconciliation module to reconciliate the two versions and save the composite as one integrated document. The reconciliation logic interacts with the DBMS, which saves the document as a single version X and deletes the two versions X.a and X.b (unless the system administrator has enabled development versioning at this lowest granularity, in which case these intermediate versions are retained to facilitate rollbacks). The reconciliation module notifies the document manager that this task has been completed. The document manager next sends mesages, via the messaging module, to inform the two authors of the action taken. The messaging module notifies the authors, via email, that their changes have been integrated into a single version and saved as X. This explanation concludes CASE 2.
If the reconciliation logic finds that conflicting changes have been made to the document, it flags these changes and informs the document manager of this status. The document manager then sends messages, via the messaging module, to inform the authors that their modifications conflict and must be resolved (possibly by using the collaborative environment). The messaging module conveys these messages to the authors via email. This explanation concludes CASE 3.