Snakelets and WSGI

[Ian Bicking]

Robert Brewer wrote:
> Snakelets are more problematic, because WSGI heavily prefers a "server
> pull" model over write() calls. You'd probably have to deprecate
> Snakelets as written (or wrap write() so it queues their output as
> well), replacing them eventually with a model that yields values rather
> than calling write().

I think this has been a little overemphasized in this thread.  The only 
place where this really matters is when you are streaming content -- 
that is, you are producing so much content that you want to start 
sending the response before you are finished with the whole thing, or so 
much content that you don't want to have it all in memory at once.  The 
only place where this really occurs is serving media files or other 
large documents.

I think it's quite valid for a web framework like Snakelets to simply 
cache the entire page, and send it in one big chunk.  StringIO is an 
easy way to do this.  Caching the result content offers other 
advantages, like allowing you to change the headers after part of the 
content has been produced (e.g., to add a cookie).

The issue with WSGI's write is that the server is supposed to send the 
content right away (or at least try) when you call it.  If you are 
generating content in small chunks (less than 1K), then you may be 
asking the server to do its work inefficiently; it probably knows better 
how much content should be buffered, and when the client is ready for 
more content.

So, mostly, just don't get too distracted by the fact that Snakelets and 
WSGI both have something called "write".

-- 
Ian Bicking  /  ianb at colorstudy.com  /  http://blog.ianbicking.org