Thanks Vincent, so the answer component can be a pyramid app doing long polling off the redis store? Do you think there is any need for getting to gevent for such a thing? (it will def be a separate python package from the upload app anyway)
On Tue, Sep 29, 2015 at 1:15 PM, Vincent Catalano < [email protected]> wrote: > 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. > -- 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.
