Could you explain to the layman how this compares to the web server that ships with Tornado? I mean more in terms of usecases rather than performance. Also, the entire Tornado stack is written to be async and non-blocking. If one was to use something like plain vanilla PHP behind your nginx module, would one get the same result? Cheers.
How would you go about restricting access to channels to a specific user or users? My first take would be to issue an unguessable id upon successful authentication and use this id as the channel id -- a shared secret. Only those who should know the id do know it.
I don't see support for streaming; the connection to the long-polling client is closed after consuming. Are you planning on adding support for streaming new messages as they are published?
"Meanwhile, you can use your application to do the authenticating, and generate ids for already-authenticated clients from a large enough (> 2^128) keyspace for security."
Everything is pretty much as efficient as vanilla nginx. There are some O(log(n)) lookups, but i've not noticed CPU usage hit anything even remotely suspicious (fixed bugs aside).
Memory usage for long-polling requests is regular nginx usage ("2.5MB for 10K idle connections"), + around a hundred bytes or so per ling-polling requests. A channel eats up about a dozen bytes.
The only limitation that one might run into is the maximum memory allotted for shared messages -- but that's a configurable value.
