[Web-SIG] PEP 444 (aka Web3)

[Gary Poster]

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.

Gary