Hoping for some advice from veterans here. We're cooking up a system that does the following:
- client angular app uploads a document (not a very frequent operation) to pyramid app - pyramid app receives it, and dispatches it to a worker over rabbitmq where many version are generated and shuffled around S3 (could take a while) - when workers are done, a message is sent, ultimately meant to trigger a callback in the client side app We need to support IE9, and we'd like to keep things as stateless and open to further distribution as we reasonably can. The simplest solution seems to be that the workers put the result into redis, and the client app polls another server-app who's only job is to hand back results from redis (json params and a token to a callback to fire). If this "answer callback server" does nothing else, it can be plenty fast and tweaked for polling. I'm not clear on whether this is a good design, and if so, what this server should be. Can it still be pyramid or is this a job for twisted/tornado/node or something? In our case, the only server push events will be *responses* to something the client occasionally initiates. So a client only really needs to poll if they have a) uploaded a file and b) not gotten their response yet. We don't need all clients polling all the time for random server events (like you would for chat, say). So I'm wondering - what should this "answer component" be? ( pyramid? twisted? use redis?) - how should the client and the answer component communicate? ( short poll, long poll, web socket?) Any thoughts on the above much appreciated! iain -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/d/optout.
