Hi,

I saw the HTTP push module and it looks like it might be ideal for my
purposes, but I am not clear how best to use it. (Linux nubie).

It seems that I set up the module and configure it to have a /publish
and /subscribe url - each using ?id=<channel> parameter, so we can have
more than one push stream at a time.

The javascript in the clients then use XMLHttpRequest to GET from the
subscribe URL. When the reply arrives, it acts upon what arrived, and
immediately issues the next GET.

Each client will also have a form which POSTs to another URL - lets call
this chat.php that will
a) Authenticate that this client may speak :)
b) Filtering - not those words, but recognising requests for info,
fetched on demand.
c) Do Logging,
d) Use the cURL library to POST what should be published to the
/publish URL
e) Return an empty 200 reply (so the page is not replaced).

I've had trouble in the past with Apache timing out long running
processes after 600 seconds. Do I need some sort of heartbeat to avoid
these problems?

The browser will time-out the subscribe request after a while. If there
is nothing broadcast for a while and the HTTP stack times out then
(IIRC) no event is called which means Javscript cannot re-issue the
subscribe. How can I code round this?

My customer wants the clients to see when someone starts to type. This
could be a message sent when the first character is entered into the
input box. When it arrives the javascript will alter the icon
representing that person. Sounds OK. Would it be fast enough?

My startup page must read the log and include all the history in the
initial page. So I will have to pass message numbers (or timestamps?)
through from the log to the initial page, to the first subscribe
request. I am not clear what to pass to the subscribe URL to get the
right messages. Note - some messages, such as the "typing" update, are
not logged!

Using this module would be a major departure from the current design (
"long polling", with a timeout of 4 seconds), but could be MUCH more
scalable.

Comments and advice welcome.

Regards

Ian










_______________________________________________
nginx mailing list
nginx@nginx.org
http://nginx.org/mailman/listinfo/nginx