[Web-SIG] PEP 444 (aka Web3)
gary.poster at gmail.com
Thu Sep 16 08:37:01 CEST 2010
On Sep 16, 2010, at 2:34 AM, James Mills wrote:
> On Thu, Sep 16, 2010 at 10:15 AM, Chris McDonough <chrism at plope.com> wrote:
Thank you for the work, Chris.
>> We can ditch everything concerning web3.async as far as I'm concerned.
>> Ian has told me that this feature won't be liked by the async people
>> anyway, as it doesnt have a trigger mechanism.
> You and Ian are right about that. I don't see the point of introducing
> an "async" property/variable into the environment data.
I've been hoping for something like web3.async.
When I saw it in the spec, I didn't see it as a way to support asynchronous applications generally. I suspect that fully async applications are just not really ultimately interested in a wsgi/web3 world--the threaded model is too different. I'd love to be wrong. (To be clear, happily some async frameworks *are* interested in being wsgi servers.)
In any case, I saw it as a way for web3 threaded applications to support long polls, from JS or some other client.
Threaded applications might authenticate and do X work, and then pass off some work significantly more appropriate for an async server back to the web3 server. That work might be proxying a file found elsewhere on an internal network; or waiting for a response from an asynchronous job in this process (Twisted) or some other one (RabbitMQ); or other similar tasks. Meanwhile, the threaded application could go off and handle more requests, having done what was needed of it.
Periodically polling the callable wasn't what I was thinking of--I had the Twisted world in mind, so I was thinking more of a Deferred type model--but polling would be good enough for my needs.
I'd like to see it, or something like it. If not, I suspect I'll be trying to hack something like this in somehow, because it addresses concerns we've had at Launchpad in recent planning sessions. I'd *much* prefer to have a supported, clean approach.
More information about the Web-SIG