Motivation and Limitations

Motivation

Electron-based client

In order to make our editor easy to use and cross-platform, we decided to use electron.

Codemirror npm package

Writing the editor mechanics is a project in its own right. Therefore, we decided to reuse a fairly known editor.

Locking versus consensus algorithms

Whenever multiple users are editing the same area in a file, conflicts will occur. The server can mitigate this by prioritizing one user or by merging the non-conflicting edits, but this usually doesn't perform as well as end-users expect. Therefore, the server either needs to have consensus algorithms like the raft-consensus algorithm or disallow these situations to occur in the first place. We have chosen the latter option, because we couldn't find a consensus algorithm that we thought could be implemented in such a short span of time and we couldn't find an algorithm that performed as well as we would expect.

However, a lock-based approach has additional benefits. It provides a clear overview of which users are editing which areas, as well as code security: an user knows a function within their lock can not be edited by other users and will thus keep working as they expect. Furthermore, things such as highlighting will stay consistent elsewhere in the file when users open highlighting delimiters (e.g. a single unpaired quotiation mark), since the original highlighting state of the lock can be retained.

Service based server architecture

When implementing the server, an overarching architecture had to be designed. In our case we decided to split up various server functions across several micro services. By employing these services, the server is more scalable in case of high demand loads. Services can even be run on different services, which could be useful if a service has particular needs, like high storage demands in case of the FileSystem service. Adding additional functionality is also easier, since this won't interfere with operation of other services. Our implementation of micro services with inter-service messages also allows for swapping out services with the same functionality, but different implementations. These differen services just need to hande the same message types.

Usage of Pyro for inter-service interactions

We choose to implement inter-service communication using Pyro, since this allows us to send Python datastructures directly, whereas, if we would have done this using for example HTTP, we would have needed to convert these objects into something which could be sent over HTTP.

Piece table datastructure

A line-based system is, in many ways, insufficient. Our first drafts used a scheme like this, which quickly presented issues in regard to the concurrent and real-time nature of our appliation. As an example, users would request an edit in a line number which might have been changed on the server as its message arrives there.

A possible solution would be to use documents uuid's, from which the user's state of the documents could be determined by the server, but we found this solution to be too complex. The piece table proved to be an intuitive solution, especially since it integrated very well with the locking idea: complete pieces within the table could easily be marked as locked.

In the end, we settled on using the piece table in both the server and client, such that clients can communicate in the same language with the server. This is advantegeous for multiple reasons, which we describe further at the piece table page. In general, the piece table solved two problems: concurrent user inputs which might have different versions of the same documents, as well as creating an intuitive implementation of the locks.

Limitations

Left-out features

We wanted to provide git-integration, but this proved to be very difficult and we didn't think this was as important as getting the core features to work. Additionally, we wanted to give the editor a bigger focus on the collaborative aspects of the editor, such as in-line comments as well as as chat features. Sadly, time limitations made these addition unfeasible.

Auto locking

It is currently not possible to move the cursor to an unlocked area and auto lock it when the user starts typing. This should not be too much work to make this, but we prioritized the minimal viable product tasks. Additionally, a keyboard shortcut for (un)locking would be very handy.