in which another mode of collaboration is set forth

When Giles tagged me with one of these blog memes that's been going around, I couldn't bring myself to continue its progression since I generally don't find them all that interesting—it takes a remarkable writer to make a good post out of one, but a remarkable writer probably could have found something interesting to write about without the meme, while with a less-than-remarkable writer I'd find a the regular fare (usually a post about code) more interesting than a biographical sketch.

However, one question in the bunch did stand out to me: what's the most fun you've had programming? In May of 2006, I wrote a collaborative editing client for Emacs called Ebby in three days. This was my first nontrivial lisp program, and it was really a rush to dive into the language/environment and come up with something useful so quickly. Ebby was actually a client for the existing Obby protocol which happened to have no documentation at the time, so I spent a lot of time in ettercap analyzing traffic in between banging out lisp functions.

While I had loads of fun working on Ebby, one vital feature kept eluding me. Since I was the only one using Ebby at that point, I was never able to trigger conflicting edits. Because of this I never saw the complicated mechanisms in the Obby protocol for dealing with conflicts. Later someone from the Obby team explained it to me, and I started implementing it. But it greatly complicated the code since much more state had to be kept client-side so that conflicting changes could be rolled back and reapplied on top of the new edits received from the server. While I was working on this, the Obby team announced they were eventually going to move to an XMPP-based protocol that would share virtually no code with the existing implementation, so I dropped my efforts to fix Ebby. It still worked quite well with version 0.3 as long as you were on a low-latency connection, since that kept the likelihood of conflicts low.

Fast-forward to September or so of last year. I was just learning about git and how its rebase operation works. I got the strangest feeling of déjavu about this until I realized it was the same rollback-and-reapply operation that I had tried to add to Ebby. I knew at some point I would want to revisit Ebby, so I filed this little tidbit away.

Later still at Railsconf '08 a few of the git-addicted hackers got together to write gitjour, a tool to share git repositories locally via ZeroConf networking. Once I found out about this, it was really just a matter of putting the pieces together before a collaborative editing tool was born out of it.

Conspire is that tool. It builds a realtime repository synchronization platform on top of gitjour and then provides editor support on top of that so your edits are automatically committed, rebased, and refreshed with of the state of the network's conspiracy session.

As always with new software, there are a number of caveats:

• Conflict resolution is more or less untested. Once again I find myself in the position of sole conspirator, so it's hard to simulate conflicting edits.
• Emacs is the only editor currently supported, naturally. But should not be hard to add support for your favourite editor, so give it a go.
• Installation depends on an unreleased gem, but if you install the conspire gem from github (after sudo apt-get install libavahi-compat-libdnssd-dev on Debian-based systems) it will pull in my custom up-to-date versions of the dependencies.
• Conspiracy sessions are currently LAN-only, no Internet support or NAT-tunneling.
• I have no idea how it will scale beyond two conspirators. The synchronization interval parameters could use some tweaking, to be sure, and it would be great if it could auto-adjust them based on network latency and number of conspirators.

It currently lives at http://github.com/technomancy/conspire. As always, patches are warmly welcomed. Give it a shot: sudo gem install conspire --source=http://gems.github.com

« older | 2008-07-30T12:34:15Z | newer »