8 ms·

While node.js has some appealing characteristics it doesn't seem to solve the main problem with realtime web apps -- coordination between the multiple client s

by equark 16y ago

While node.js has some appealing characteristics it doesn't seem to solve the main problem with realtime web apps -- coordination between the multiple client side view states and the server side state. It's easy enough to hack together communication between these two layers but it always feels a bit half baked. Something like etherpad should be the new hello world app.

aaronblohowiak 16y ago
Groupware is an extraordinarily difficult problemin this respect, especially if you want to handle the rare edge cases. The problem with maintaining multiple client side view states to be the same has a great deal of intrinsic complexity due to the very weak guarantees provided by network communication (if you want any kind of responsiveness whatsoever.)
- equark 16y ago
  True, but I suspect there is a lot that could be done by baking something like the feedsync protocol together with knockout.js style view binding, node.js and a websocket connection.
  - aaronblohowiak 16y ago
    The problem with feedsync and trying to serialize knockout.js to disconnected clients is conflict handling. Secondly, you have to worry about potentially divergent states if messages are lost in-transit (depending how robust your needs are.) That being said, you could hack something together with a very optimistic approach using knockout.js and socket.io (to gracefully degrade if websockets arent available.)
- jchrisa 16y ago
  I tend to solve the problem of showing the same state to all users with the CouchDB _changes feed. It fits the groupware problem like a glove. Here's just one example app: http://couchapp.org/focus/_design/focus/index.html http://couchapp.org/focus/_design/focus/index.html
simonw 16y ago
Have you seen DNode? http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-Method-Invocation-for-Node-js-and-the-Browser http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-M... Doesn't solve that problem (which is really, really hard) but it's a very interesting step.

by equark 16y ago

aaronblohowiak 16y ago

Groupware is an extraordinarily difficult problemin this respect, especially if you want to handle the rare edge cases. The problem with maintaining multiple client side view states to be the same has a great deal of intrinsic complexity due to the very weak guarantees provided by network communication (if you want any kind of responsiveness whatsoever.)

equark 16y ago
True, but I suspect there is a lot that could be done by baking something like the feedsync protocol together with knockout.js style view binding, node.js and a websocket connection.
- aaronblohowiak 16y ago
  The problem with feedsync and trying to serialize knockout.js to disconnected clients is conflict handling. Secondly, you have to worry about potentially divergent states if messages are lost in-transit (depending how robust your needs are.) That being said, you could hack something together with a very optimistic approach using knockout.js and socket.io (to gracefully degrade if websockets arent available.)
jchrisa 16y ago
I tend to solve the problem of showing the same state to all users with the CouchDB _changes feed. It fits the groupware problem like a glove. Here's just one example app: http://couchapp.org/focus/_design/focus/index.html http://couchapp.org/focus/_design/focus/index.html

simonw 16y ago

Have you seen DNode? http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-Method-Invocation-for-Node-js-and-the-Browser http://substack.net/posts/85e1bd/DNode-Asynchronous-Remote-M... Doesn't solve that problem (which is really, really hard) but it's a very interesting step.