These are not common/generic use cases but would be useful under particular circumstances.
* I could be wrong with (3) -- I'm not very experienced in reverse proxies.
It wasn't quite dynamic (it required an engineer to set new values for how many workers you wanted..) but we could do this via a GUI.
For (1) what do you do with the persistence? A web request, in general, is not important after a few seconds.
For (2) how does Polyglot accept multiple responders for a single request, and how would it join the responses?
The implementation today is as a task queue which removes the request from the queue once a responder acknowledges, but it could be a pub-sub model, where a number of independent responders can work on the same message in parallel, and only 1 responder need to return a response. In this case, persisting in the queue is useful.
An alternative is to chain the responders where one responder can leave a message in the queue for another responder, and the final responder returns the response.
Polyglot is still experimental though, and the current implementation is a prototype.
The rest of the web works on "push" too; pull in this case would only help if you don't care that a request could take a long time (seconds) to resolve.
I didn't see mention of it, but what happens if a message is not responded to? How does Polyglot handle time outs?
That way you can leverage any existing language frameworks and run them as standard HTTP responders. No need to work with a queue (and add it to the stack).
You can still limit the HTTP methods each proxy responds to as well [2].
[1]: http://nginx.com/resources/admin-guide/reverse-proxy/
[2]: http://stackoverflow.com/questions/8591600/nginx-proxy-pass-...