Background

For years I've been intrigued by collaborative text editors -- programs that let two people work on the same document at the same time without getting in each other's way. To do this well is actually not an easy task, especially when you start to consider things like unreliable networks that drop packets, variable latency, etc. An engineer at Google described an algorithm for working on this problem. I used this to create a general model for communicating between multiple nodes in a peer to peer network while collaborating on a single text document. The model provides for synchronizing changes across different "channels" of communication. I tried to design it in such a way that it can grow over time to allow new means of "talking" between different computers.

For example, one "channel" is to share a text file. Each instance of Composer uses that file to communicate changes back and forth to other nodes. Very easy to do, but not very useful since it requires two users to be on the same computer. But it was helpful in testing.

A more useful channel is Dropbox. You can already work on a file in your Dropbox folder in Composer, and changes are automatically propagated to other computers. You can even work on the same file on two different computers. The problem here is that changes are only communicated when you save a file. If two people save at the same time, you can get conflicted versions, and then you have to disentangle them. But it's very useful if you're moving back and forth from home to work and left a file open, for example.

Even more useful is to use Dropbox as a communication API between nodes. Rather than saving and reading the file on disk, Composer communicates directly to Dropbox servers and uploads/downloads the text automatically. It uses an algorithm to adjust polling intervals to refresh more quickly when users are typing, and to slow down when they're not. If two people make changes at the exact same time, the code detects this and does its best to reconcile the differences and show each user the proper combination of changes. This process is not always perfect, as two users could theoretically both alter the exact same part of the document in different ways. But in this case, both users see the same final result and can fix the discrepancies -- they won't end up with two different versions of the file that have drifted apart.

I've actually been working on this off and on for 2 years or so, but finally had a chance to get the Dropbox channel working reliably enough that I think it could be used for public testing. Not everyone needs real time collaboration on text documents, but I think this is a great solution for those who do. Plus it's interesting technology in a really geeky way.

I'm consider developing other "channels", but these are going to take some time. I think it's reasonable to get the Dropbox collaboration out in the open for additional testing, and hope to provide other channels in the future. (As always, I can't promise anything for the future.)

For those who would like to see a specific channel developed, the thing to keep in mind is that for the system to be reliable I have to be able to tell whether the information on a server matches the information I last sent it, or whether someone else has changed it. For example, the last time I looked at it, I could not reliably use iCloud Drive for this sort of an approach. I also don't think that BitTorent Sync would work. Another obvious approach is a custom server/client protocol. I'm not ruling this out, but creating this will get into all sorts of network problems that I am not an expert in (peer discovery, firewalls, etc.) I also thought about Multipeer Connectivity, but at the time it was limited to iOS. It seems Apple finally brought this to OS X, so that might be an interesting option -- but it would be limited to collaborators in the same physical space (great for classrooms???). (Oh, and BTW -- the infrastructure I created is specifically designed to allow for multiple connection types between nodes in a peer-to-peer manner. So it would be possible to use MultiPeer for a few users in one location, while one of those users has dropbox enabled to communicate with a remote location. Some interesting possibilities, but just not sure how many people need something like this!)

What Are the Problems?

The main issue that this approach raises is that Undo/Redo as implemented by the OS is no longer reliable. For example, if you and I both make a change simultaneously, there's no way for me to undo my change without disrupting your change.

To get around this requires a much more sophisticated undo/redo mechanism. Something else that got really interesting the more I read. And surprise, surprise, also something I have been working on for a while.

I'm in the process of developing a smarter undo/history system for Composer. I have a rough prototype developed, but it needs some reworking for MMD-5 and needs a lot more testing. But the basic idea is that it can allow me to undo/redo my changes in my part of a document, without affecting what you do in another part of the document. If your changes interfere with mine, the system is able to account for that and prevent me from messing things up.

So, for now, Undo is basically disabled with using Dropbox collaboration. Once I get the new undo mechanism working, that will be added for additional testing as well.

Is That It??

Well, I after seeing how complex all of this is, I actually think that it's pretty impressive.... ;)

But no, that's not it.

While thinking about this undo mechanism, it also occurred to me that undo/redo is really nothing more than moving through changes to a document over time. Which is exactly what change tracking handles..... In other words, the CriticMarkup/Track Changes functionality is very closely tied with the concepts of undo/redo.

There's no reason that we can't find some ways of integrating these features in some ways. In other words, you could take your undo/redo history from a session of working on a document and save that using CriticMarkup into the document itself. Or you could load the CriticMarkup changes and build an undo history out of that.

And with an advanced system like this, there's no reason you can't go back in time and undo one change from 10 minutes ago, and then redo everything else (e.g. Selective Undo).

What Next?

So -- if this sort of thing sounds like a feature you would love to have, buy the Pro version of Composer when it's available. Unfortunately, I have bills to pay and can't spend all my time working on software for free. MultiMarkdown Composer is mostly a passion project -- I make a little bit of money of it, but it doesn't come anywhere near providing enough income to live off. Which is fine.

But certainly, the more support I have from users who appreciate these sorts of cutting edge features that are really hard to find in other applications, the more motivation I have to work on solving these challenging problems.

An email expressing your interest wouldn't hurt either!