7

Looking into Meteor to create a collaborative document editing app, because it’s great that Meteor synchronizes data between multiple clients by default.

But when using a text-area, like in Sameer Kalburgi’s example
http://www.skalb.com/2012/04/16/creating-a-document-sharing-site-with-meteor-js/
http://docshare-tutorial.meteor.com/
the experience is sub-optimal.

I tried to type at the same time with a colleague and my changes would be overwritten when she typed and vice versa. So in the conflict resolution there is no merge algorithm yet, I think?

Is this planned for the feature? Are there ways to implement this currently? Etherpad seems to handle this problem rather well. Having this in Meteor would make creating collaborative document editing apps way more accessible.

Eric Schrijver
  • 219
  • 1
  • 9

3 Answers3

8

So I looked into it some more, the algorithm used in Etherpad is known as Operational Transformation:

The solution is Operational Transformation (OT). If you haven’t heard of it, OT is a class of algorithms that do multi-site realtime concurrency. OT is like realtime git. It works with any amount of lag (from zero to an extended holiday). It lets users make live, concurrent edits with low bandwidth. OT gives you eventual consistency between multiple users without retries, without errors and without any data being overwritten.

Unfortunately, implementing OT sucks. There's a million algorithms with different tradeoffs, mostly trapped in academic papers. The algorithms are really hard and time consuming to implement correctly. We need some good libraries, so any project can just plug in OT if they need it.

Thats’s from the site of sharejs. A node.js based ot server-client that you can hook into your existing client.

OT is also implemented in the Racer model synchronization engine for Node.js, that forms the underpinnings for Derby. At the moment, derby.js doesn’t transparently provide it yet, but they plan too, from the Derby docs:

Currently, Racer defaults to applying all transactions in the order received, i.e. last-writer-wins. (…) Racer [also] supports conflict resolution via a combination of Software Transactional Memory (STM), Operational Transformation (OT), and Diff-match-patch techniques.

These features are not fully implemented yet, but the Racer demos show preliminary examples of STM and OT.

Coincidentally, both the sharejs and derbyjs teams have an ex Google-waver on board. Meteor has an ex etherpad/Google Waver in their core team. Since Etherpad is one of the best known implementations of OT I was imagining Meteor would surely want to support it at some point as well…

Eric Schrijver
  • 219
  • 1
  • 9
4

I've created a Meteor smart package that integrates ShareJS:

https://github.com/mizzao/meteor-sharejs

It's quite preliminary right now, but you can import it into your app, drop in textareas, and it "just works". Please try it out and submit some new features via pull requests :)

Check out a demo here:

http://documents.meteor.com

Andrew Mao
  • 35,740
  • 23
  • 143
  • 224
0

What you describe seems out of Meteors scope for me. Its not a tool to set up collaboration possibilities!

What it provides is a way to transparently work against a subset of a servers database. But the implementation of use-case specific merging functionality is the job of the application, not the framework.

Marcus Riemer
  • 7,244
  • 8
  • 51
  • 76
  • 1
    IMHO the whole point of these kind of applications is not just that clients synch with the server transparently, but that through this, all the connected users synch with each other. If that’s not set up for collaboration possibilities, I don’t know what is! – Eric Schrijver Aug 14 '12 at 19:31
  • 1
    And since conflict resolution is built into Meteor it seems not such a strange question to ask if it can be more sophisticated. But of course, if you know a good way I can hook into the conflict resolution mechanism myself I’d like to know. – Eric Schrijver Aug 14 '12 at 19:34
  • 1
    Okay, my wording may have been a little off. What I meant is that Meteor does of course support collaboration scenarios but is not explictly geared towards it. So you have to expect some rough edges here and there. What do you mean about "conflict resolution is built in"? Everything I could find in that direction in the docs is that in conflict scenarios the first client side subscription always wins. – Marcus Riemer Aug 15 '12 at 17:52