<html style="direction: ltr;">
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <style type="text/css">body p { margin-bottom: 0cm; margin-top: 0pt; } </style>
  </head>
  <body style="direction: ltr;"
    bidimailui-detected-decoding-type="latin-charset" bgcolor="#FFFFFF"
    text="#000000">
    I'll point out two possibly obvious things:<br>
    <br>
    1. Most of what we consider "web" is indeed really "synchronous," in
    that there is likely a thread doing something (quickly if you want
    to scale!) and then sends us a response. But, there's nothing in
    particular that says that an asynchronous server can't handle that
    at the low level. Indeed, plenty of people build traditional web
    servers over asynchronous servers such as Tornado, Node.js or Jetty.
    I maintain that they often are doing so for the wrong reasons:
    asynchronicity does not guarantee graceful deterioration, especially
    if you (most likely) have a thread pool on top actually generating
    the content. (And, actually, many of the web servers that perform
    best under load are "synchronous" servers. They're just very smart
    about handling load, duh.) As a side note, there are implementations
    of HTTP/1.1 chunking that create better throughput via <i>some</i>
    asynchronicity at the server level. As far as I know, this is not
    part of the WSGi spec, but some implementations may cache entities
    and chunk them... although, I would be surprised if any Python WSGi
    server does that. Would love to hear otherwise!<br>
    <br>
    2. Actually, the Comet protocol for AJAX is truly asynchronous, in
    that a connection from the client is opened and stays open. They are
    not typical client-server requests by any means: if each of these
    connections held a thread on the server, you can forget about
    scalability. They are also not very typical AJAX, but some people
    like them. Again, not something that WSGi can help you with.<br>
    <br>
    -Tal<br>
    <br>
    <div class="moz-cite-prefix">On 10/10/2012 11:14 PM, Jordan Bettis
      wrote:<br>
    </div>
    <blockquote cite="mid:507647AC.2040100@hafd.org" type="cite">
      <pre wrap="">On 10/10/2012 08:48 PM, JS Irick wrote:
</pre>
      <blockquote type="cite">
        <pre wrap="">Good evening Jordan-

Can you explain what you mean by "doesn't support async"?  Asynchronous processes, asynchronous JavaScript, or something else?  I have pretty strong memories of using Ajax regularly from within django. (Basically using templates to build simple Json web services). 
</pre>
      </blockquote>
      <pre wrap="">
I mean asynchronous server responses. Which is to say, a server receives
a request, processes it for a time, makes a request on some other
service, and then sets the request aside, to handle other requests.
Later, when that other service returns its response, the server finishes
processing that request and returns it to the client.

Suppose you have a site which has a text search function. Your website
is a 'standard' webapp which has a number of worker threads which
receive requests, and process them into responses. But because search
takes so much time, that's separated out into a dedicated process. When
a worker receives a search request, it passes it on to the search server.

But if there's no mechanism for setting the request aside, the the
worker thread has to sit around doing nothing while the search server
does its thing. An asynchronous framework would let the worker set the
request aside and process new requests while it's waiting for the
response from the search server.

This is irrelevant to ajax because ajax is about client-side
asynchronous requests. From the view of the server, each ajax call is a
typical request-response synchronous cycle.

WSGI doesn't support setting a request aside and processing others. When
a request is made on a worker through WSGI, the worker is expected to
generate a response *before* starting work on another request.

_______________________________________________
Chicago mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Chicago@python.org">Chicago@python.org</a>
<a class="moz-txt-link-freetext" href="http://mail.python.org/mailman/listinfo/chicago">http://mail.python.org/mailman/listinfo/chicago</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>