[erlang-questions] comet

[Robert Smart]

I never get around to writing my erlang/javascript ajax application,
but I keep thinking about it.

There are complicated solutions to the message passing problem, like
cometd in the dojo toolkit. I have always thought that I'll be able to
get away with a simple system like this:

The server has 4 erlang processes: HC receives messages from the
client (as POSTs with JSON); HS receives requests from the client for
new messages from the server (GETs to which it responds with a
"text/json"); APP is the application; SQ holds the queue of messages
to go to the client (which are sent when GETs come in to HS).

SQ loops receiving two sorts of messages. One sort of message from APP
contains a message to pass to the client. These get accumulated. The
other sort of message is from HS asking for any messages. When the
latter arrives then all the awaiting messages are returned to HS which
will package them up as a "text/json" response. If there are no
messages to return then there is no immediate response to HS. Instead
SQ goes back to listening for local messages: if it gets one from APP
it sends it to the HS; if it times out (20secs?) then it returns an
empty message list to HS which returns that to the client. So the
response to GETs coming in to HS can be delayed up to the timeout.

When POSTs come in to HC then the message is written to the queue of
unprocessed requests in static storage (disk), before returning a
response which is the same as an empty HC response (only has an
updated last seq number received). I guess there is a problem sending
this using XHR (XmlHtppRequest), since we already have one active
waiting for HS response. So maybe this does have to be sent through a
separate (i)frame. Or maybe we can have 2 simultaneous XHRs if they go
to different ports? Of course it is moments like this that you want a
toolkit like dojo to smooth over the differences between browsers.

The client javascript keeps an XHR request up to HS (whenever it gets
a response, or a request fails, then it starts up a new one before
doing anything with the returned data). For sending data it just sends
to HC (maybe a different port) whenever it has a message to send, and
doesn't expect a response. If the sends to HC fail then they will be
resent after a wait [with some sort of visual indicator for the user
that there is delay]. When there is a delay then multiple messages can
be combined in the catch up retry.

JSON messages between client and server have a sequence number. Each
time a collection of messages is sent then the sequence number of the
last received message is also sent. Always (re)send all the messages
since the last known received message. Messages that have already been
received are ignored. If the next expected message is bypassed then
crash.

All state is kept in the server and saved before a related response is
sent to the client. So if the server restarts and the client keeps
trying it will resync on the restarted server. If the client browser
restarts then going to the initial url for the application will tell
the server to resync and send the client enough data to rebuild the
gui state.

Will this work?

What tools are relevant?

Bob