Hello Iain, It looks like you are going in the right direction. Unfortunately, since you are supporting IE9 you are a bit limited with what you can work with. Although there are some workarounds and poly-fills for web sockets in IE9, I definitely think that long polling is the way to go. As far as your "answer component", I think the best and simplest approach would be to use your existing Pyramid app with Redis. Whenever your client requests the status of the file, the lookup in Redis should be relatively quick - no need for an asynchronous web server or web sockets.
-Vincent On Tue, Sep 29, 2015 at 12:15 PM, Iain Duncan <[email protected]> wrote: > 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. > -- Vincent Catalano Software Engineer and Web Developer, (520).603.8944 -- 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.
