I'm waiting for an account at http://prgmr.com/ so I can start putting up live demos of my stuff. In the meantime, if anyone has suggestions for a cheap VPS to put something like this up on, that'd be awesome (the cheapest I know is Linode, but 19.95 a month is a bit much for random screwing around).
We'd love to host you at ElusiveHippo.com - it's like Heroku for nodejs apps. Email me at van@elusivehippo.com and I can set you up with a beta account.
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.
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.
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
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.
Looks amazing! I'm working on a diagram editor (UML and business processes) for Google Wave where we had to solve command ordering/merging and a lot of similar problems.
We developed a javascript library to synchronize a command stack between clients and resolve all ordering problems that could occur due to commands arriving very late. Having a server like you do for synchronization and that stuff would make those issues nearly trivial to solve- but as Google Wave only provides a synchronized key-value storage we had to roll our solution client side only.
Very cool. When I did http://flockdraw.com with @lunixbochs 6 months ago we really wanted to do it without flash but the updates-per-second really didnt cut it. Looks like thats starting to change (which is awesome). One of the features we really wanted was a iphone version/app but we wouldnt be able to use a flash socket shim on iphone, hence a total rewrite needed.
14 comments
[ 4.5 ms ] story [ 39.8 ms ] threadyou get a free month per person signed up, if you have a semi popular blog or tool then you can usually get enough to cover your hosting.
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.
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
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/
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)
We developed a javascript library to synchronize a command stack between clients and resolve all ordering problems that could occur due to commands arriving very late. Having a server like you do for synchronization and that stuff would make those issues nearly trivial to solve- but as Google Wave only provides a synchronized key-value storage we had to roll our solution client side only.
You might want to check out our approach in a little more depth at http://www.processwave.org/2010/02/syncro-real-collaboration... or take a look at the very well documented code at the bitbucket: http://bitbucket.org/processwave/syncro
We are planning on adding a paint canvas to our app, and yours looked the best I saw so far in a webapp. Cool work, it's not trivial stuff :)
Again- Very cool :)