[Web-SIG] WSGI async API

Carlos Ribeiro carribeiro at gmail.com
Fri Oct 15 20:10:08 CEST 2004

On Fri, 15 Oct 2004 18:06:02 GMT, exarkun at divmod.com <exarkun at divmod.com> wrote:
> On Fri, 15 Oct 2004 14:51:54 -0300, Carlos Ribeiro <carribeiro at gmail.com> wrote:
> >On Fri, 15 Oct 2004 13:24:19 -0400, Peter Hunt <floydophone at gmail.com> wrote:
> > > Essentially, Twisted.Web gives you something like this:
> > >
> > > class MyResource(resource.Resource):
> > >     def render(self, request):
> > >         return "content here" # you could also do request.write("content here")
> > >
> > > If you do an async call, you have to use request.write() to write the
> > > data, return server.NOT_DONE_YET from the render() method, and call
> > > request.finish() to finish the request.
> >
> > Just curious, so forgive me from jumping into the middle of the
> > discussion. Isn't this one of the scenarios where output generators
> > are most useful? Assuming that Twisted supported it, you could yield
> > lines until there were nothing else to write. Did I get it right?
> >
>   Only if you can also signal to the code which is iterating the generator that it should stop iterating it for a while, otherwise user code might be called upon for bytes before they are available.
>   If I have understand the conversation on the matter then this caveat is a main stumbling block for the async wsgi api.

Now I think I get it. Generators have only two "states" of sort:
either they can return more lines, or they stop. But the async API
wants to have a three-state signaling protocol: ready to provide more
lines, no more lines, and a "please, wait a second while I prepare
more lines".

That's it?

Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: carribeiro at gmail.com
mail: carribeiro at yahoo.com

More information about the Python-list mailing list