4 ms·

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 d

by saikat 16y ago

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 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.

daleharvey 16y ago
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
tlrobinson 16y ago
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.
- pg 16y ago
  If you represented drawings as text (e.g. as postscript) you could use the rest of the code unchanged.
  - saikat 16y ago
    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/ http://www.waveprotocol.org/ and http://code.google.com/p/wave-protocol/source/checkout http://code.google.com/p/wave-protocol/source/checkout Mobwrite: http://code.google.com/p/google-mobwrite/ http://code.google.com/p/google-mobwrite/ Etherpad: http://code.google.com/p/etherpad/ http://code.google.com/p/etherpad/
    - sayrer 16y ago
      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-updates/ 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)
      - saikat 16y ago
        I didn't know about sync.js - this seems like exactly what I want.

by saikat 16y ago

daleharvey 16y ago

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

tlrobinson 16y ago

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.

pg 16y ago
If you represented drawings as text (e.g. as postscript) you could use the rest of the code unchanged.
- saikat 16y ago
  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/ http://www.waveprotocol.org/ and http://code.google.com/p/wave-protocol/source/checkout http://code.google.com/p/wave-protocol/source/checkout Mobwrite: http://code.google.com/p/google-mobwrite/ http://code.google.com/p/google-mobwrite/ Etherpad: http://code.google.com/p/etherpad/ http://code.google.com/p/etherpad/
  - sayrer 16y ago
    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-updates/ 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)
    - saikat 16y ago
      I didn't know about sync.js - this seems like exactly what I want.