Hacker News Reader

Comment by daleharvey | Hacker News Reader

cool demo, I worked on collaboration for inkscape in google summer of code, while it never ended up production quality, it was quite enjoyable to work on and very cool to see working.

I would take a look at using existing chat servers like ejabberd as the backend as opposed to writing your own, a lot of the complexity involved, especially when you go to > 2 room is the synchronisation and ordering of messages between all participants and chat server come with some free help with that.

View on HN

Thanks for the suggestion. Did using chat-based backends help much though? It seems like the hard part is in merging user actions when doing a collaborative drawing-like app (like Mockingbird). Chat servers, AFAIK, can just push messages onto a stack. I asked about this in another thread - http://news.ycombinator.com/item?id=1280135 . Other than Google Wave, there don't seem to be too many frameworks out there that do the brunt of the work for me.

EtherPad is open source now. Granted it's a totally different application than drawing, but who knows, some of the code might be interesting/useful.

If you represented drawings as text (e.g. as postscript) you could use the rest of the code unchanged.

If anyone else is curious, the Wave protocol is also open source, as is Google Mobwrite (which uses differential synchronization instead of operational transformations (which is what Wave and I think Etherpad uses)).

My "drawings" are represented by text (JSON), and if normal text merging methods will work, I might want to use differential synchronization (seems easier). But I wish there was something proving that it won't mess up the integrity of my structured data.

Links:

Wave protocol: http://www.waveprotocol.org/ and http://code.google.com/p/wave-protocol/source/checkout

Mobwrite: http://code.google.com/p/google-mobwrite/

Etherpad: http://code.google.com/p/etherpad/

you can use a file synchronization algorithm. here's one I did for JSON:

http://blog.mozilla.com/rob-sayre/2008/02/15/restful-partial...

It works well except when array elements move around (that works, it's just unintuitive)

I didn't know about sync.js - this seems like exactly what I want.

my history is hazy, but I remember the chat protocol was a good help when doing the handshake on a new user entered a group session with multiple users.

the merging user actions basically worked by keep a revision number of every object they store, when you make a change you broadcast with an incremented revision, if you recieve an out of order revision you ignore and the broadcaster needs to revert their change on receiving an in order change, this means you need to ensure the order of the message to each client so everyone gets the changes from A before they get it from B, otherwise one might keep A's change and ignore B's, and another will keep B's change and ignore A's

you can trade off memory with the granularity of what you store revisions against, so you can store a revision for the square X, or for the width of square X, a finer granularity allows people to change the background color and move it at the same time, if you store the revision against the square as a whole then those changes conflict.

again this was quite a while ago so might not be the best advice. but hope it helps

Reply on news.ycombinator.com