GOCollab — Peer to Peer Document Collaboration
Claus Schwarm and Martin Sevior show how GNOME Office applications, in particular Gnumeric and AbiWord, can be connected to allow multiple authors to directly collaborate on document creation. Welcome to Peer to Peer Collaboration for GNOME Office!
Bob and Jane have a problem. Both have the same employer but Bob works in the United States Marketing department and Jane in the Development lab in Europe. They were just assigned a presentation about the upcoming new company product at the conference in Asia next week. Now they need to write the underlying document.
While this is a hypothetical story, it is not uncommon for people today to form teams to work on a single document. Another common case is to edit a certain document from different computers; such as the office workstations, a personal computer at home, a mobile device.
The usual solutions to such problems are either to synchronize changes regularly between all parties or to store the document at a central place that is accessible through a network.
Developers usually use the latter method when they work on documents that direct the build of software. So called revision control systems work on a central server and enable developers to check out a copy of a document, edit it, and commit the changes back to the central server. In practice, this also means that one must update the local copy of the document often, to include changes that others have made elsewhere and to avoid eventual conflicts. A conflict occurs when at least two people edit the same part of the document so that the revision system is unable to merge both changes into each other.
Bob and Jane could use the revision marks system used within AbiWord to coordinate their work on the common document. However there is always a lag between Bob and Jane seeing what each other writes. This always slows down the development of documents as each person needs to make sure their changes fit into what the other person is doing.
Thus they will probably use the most common method today: sending copies of changed documents to each other by e-mail. As a result, both Bob and Jane will spend a large part of their time to find out what the other one changed and merge these changes back into their local versions.
This may work when only two parties are editing a single document. But it becomes significantly more difficult when three or more parties try to coordinate their changes.
The next major version of GNOME Office will introduce a new way of handling the problem, called GOCollab. GOCollab will basically marry the already built-in revision systems of Abiword and Gnumeric with a P2P network comparable to file sharing applications like Gnutella or eMule. This means that neither Bob nor Jane nor anybody else needs a central server to be set up and run, and most of their changes to a document will be merged together automatically.
GNOME Office currently consists of AbiWord, Gnumeric and GNOME-db.
Imagine then, that Bob and Jane are using AbiWord for their task to write a common document for their presentation. They will first need to agree on who’s hosting the original file. Let’s say Jane starts the document because she’s got a better overview on the features of the new product. Jane then opens AbiWord, makes a new document, writes an initial paragraph, and saves it as usual.
Although the user interface of GOCollab is not yet fixed, Jane’s GOCollab-enabled Abiword will probably have two new options under the existing File menu: ‘Offer Collaboration’ and ‘Join Collaboration’.
When Jane clicks on ‘Offer collaboration’, a collaboration server is started on Jane’s computer that allows other people to join and start collaborating on the current document. Bob’s problem is now to find the new collaboration server on Jane’s machine.
Bob thus starts AbiWord on his machine and clicks ‘File’ -> ‘Join collaboration’. He will then see a dialog asks that lists all offered collaboration documents on his network. But how does AbiWord knows about these documents?
There are two mechanisms that can be used to find and join a collaboration server:
- A direct IP/Hostname based connection. When Jane clicks ‘Offer Collaboration’, the connection details of her machine are presented to her. She can send these to Bob or to anyone else.
- Discovering offered collaboration services using libHowl. LibHowl allows applications to browse and publish services via Zeroconf multicast DNS service discovery. This works over a VPN or within some trusted IP domain. Bob just browses the computers presented until he discovers Jane’s offered document.
Once Bob discovers Jane’s document and attempts to join in, Jane will be given opportunity to confirm or deny his request.
When a connection is established, the server transmits the originating document to the client as a gzipped XML file (*.zabw for AbiWord, *.gnumeric for Gnumeric). A new view on the “remote document” is created and the user can start modifying the document.
In contrast to other schemes, the ‘remote document’ is not really ‘remote’ but local. Bob will see the document in Nautilus like any other file, open it like any other file, and save it like any other file. The difference is that Bob can see Jane’s changes exactly as she makes them and Jane can see Bob’s changes exactly as he makes them. Both documents are always the same. So as Jane types in her document Bob sees his document change. As Bob types in his document, Jane sees Bob’s changes.
Now either Bob or Jane can allow other people to join the collaboration. So the collaboration can grow as big as it needs to be.
Abiword and Gnumeric both implement Model-View-Controller (MVC) paradigm of document creation.
The Model – View – Controller pattern is a way of organizing source code. The Model can be described as the software’s internal representation of content such as documents. The View is responsible for how the internal representation is presented. The Controller is responsible for managing changes to the Model.
The MVC pattern is just a way of organizing source code. The concrete implementation usually differs between different applications.
Abiword, for example, records changes to the Model via ChangeRecord objects. A series of ChangeRecords represent how you altered your document. Gnumeric works quite similarly, but calls its changes ‘Cmd’. One could say that Abiword or Gnumeric already work as revision systems internally. In other words, both Abiword and Gnumeric don’t work with your document directly, but with a recipe of how to build it. Whenever you request a change to your document or spreadsheet by hitting a key or clicking a button, a new command is added to the recipe.
However, humans would rather not work with a recipe. They want the cake. Thus, so called ‘Listeners’ are attached to every model in Abiword. They convert ChangeRecords into a physical file on your hard disk, or to a nicely formatted display on your monitor. Whenever a new command is added to the recipe, corresponding ChangeRecords are created and the application interprets these to build a new version of your document that is shown on your monitor screen or stored on your hard disk.
Every ChangeRecord has a corresponding inverse ChangeRecord that undoes whatever the ChangeRecord actually implements. So for example the inverse of inserting 4 characters of text at a given point in the document is to delete 4 characters of text. As a result of the implementation of ChangeRecords and Cmds, you can undo every action you’ve applied to your documents or spreedsheets: it’s just a matter of performing the inverse operation of the ChangeRecord.
Now, it’s just a small step to take a Change Record or Cmd, and send it over the network to another computer. The instances of Abiword or Gnumeric running on the second computer then just need to catch the ChangeRecord or Cmd and add it to an existing copy of the document or spreadsheet at the correct position.
AbiWord already uses so-called translators to catch a ChangeRecord and apply it to a document. This is used for clipboard operations. If you paste text into Abiword translators catch this and build a set of ChangeRecords that are applied to the document.
Thus there are two main elements to the new GOCollab feature: Listeners and Translators on the one hand to convert changes into network packages and back, and a P2P network on the other hand to transport these packages to participating applications on different computers.
A tricky question remains: How do we deal with network latencies? The fundamental problem is that Jane and Bob could get their documents out of synch because it takes a finite time for changes from one user to propagate over the network to the other’s computer.
Imagine for example, Bob adds a word or character at the end of the document. This forms a ChangeRecord which then travels over the network to Jane. Due to network latencies, this may take some time. Meanwhile, Jane adds also a word or character at the end of the document which forms a ChangeRecord. Thus, from the point of view of Jane’s Abiword, Bob’s ChangeRecord should be applied where one already is: At the end of the recipe, in the same position! This is a problem.
The solution, however, is rather simple. Every ChangeRecord gets a unique number that is increased. A proper document thus consists of ChangeRecords numbered 1, 2, 3, 4, 5, for example.
By transmitting not only the ChangeRecord but also its number, Jane’s Abiword will be able to tell that Bob’s ChangeRecord has the number 6 which already exists because Jane edited the document already.
Thus it will be able to change Bob’s ChangeRecord in two ways: First, it will increase the number of Bob’s ChangeRecord from 6 to 7. Second, it will change Bob’s ChangeRecord itself because Bob’s change affects the same place within the document.
Every ChangeRecord already includes information about the place. This is because AbiWord’s document’s are structured: Every single letter, field, image or format mark has a unique position within the document. Think of it like another series of numbers 1, 2, 3, …, 10, 11, 12.
Bob’s ChangeRecord affects the place 12 as does Jane’s. Thus, AbiWord will not only need to change the number of the ChangeRecord from 6 to 7, it will also need to change the place from 12 to 13.
This may not result in what Bob and Jane want. Bob’s change is now inserted after Jane’s in the document. Both may have wanted it to be the other way around. This is a conflict because Bob and Jane worked at the same place within the document, within the same period of time. Such conflicts are unavoidable because software is not yet able to tell what its users really want.
However, the larger a document, the more information about places are available. Thus, AbiWord’s algorithm to merge ChangeRecords has more information to determine the proper place, and change the place information accordingly. An initial outline of a document helps to prevent conflicts and there will be a deal of social engineering required to work collaboratively anyway. If the users keep mostly to their assigned parts of the document things will work much better.
GOCollab enables a new level of connectivity and collaboration between people. Any change to a document made by any user in the network is automatically distributed across the entire network of connected machines. This technique can also be used to update remote documents stored on a central server. The recent introduction of the Nokia 770, which will ship with both AbiWord and Gnumeric, allows an unprecedented opportunity for collaboration and connectivity by using GOCollab. Users will be able to collaborate on documents immediately anywhere and at anytime.
At present GOCollab exists as a specification and preliminary plugin for AbiWord. The network code used to transmit packages can be reused from other packages. The conflict resolution algorithms have been implemented as a demonstration program in Python. We’re currently devoting our limited resources to completing our next stable versions of AbiWord and Gnumeric in time for the GNOME-2.12 release. We plan to offer GOCollab for the subsequent stable releases of AbiWord and Gnumeric.