ANN: Snakelets 1.35 (simple-to-use web app server with dynamic pages)

Alan Kennedy alanmk at
Tue Oct 12 08:11:07 EDT 2004

[Alan Kennedy]
 >> Have you considered maybe porting Snakelets to WSGI? WSGI is a new
 >> server/gateway standard for portability of python web frameworks, and
 >> is specified in PEP 333.

[Irmen de Jong]
 > Errm, I was only very vaguely aware of something like the WSGI,
 > and apparently totally missed the surfacing of PEP 333.
 > Thanks for dropping the link, I will certainly study it.
 > Based upon your comments below, I'm almost certain that there
 > will be some form of WSGI in a future Snakelets version.

Sounds great. I'm sure you won't regret putting in the work to port 
Snakelets to WSGI.

I'll do my best to answer your questions.

 >> WSGI specifies a HTTP API which is implementable on most conceivable
 >> web platforms. Code built on this API is fully portable to
 > [...]
 > Does it achieve this by providing a least common denominator featureset?
 > How does it deal with the way the server is structured (threading,
 > sessions, shared resources)?  I'm sorry- if this is in PEP-333, I'll
 > find out soon enough :)

The feature set is pretty much a lowest common denominator. But don't 
mistake that for meaning that it's simplistic: it's not. WSGI is really 
an interface that has factored out all of the possible complexity 
associated with dealing multi-threading, mutli-processing, etc, etc, and 
which enables applications and frameworks to make a choice on how they 
operate, depending on how the containing WSGI server has been configured.

As for sessions, shared resources, page templating, etc, etc, these are 
application and framework concerns, not server concerns: therefore WSGI 
is currently agnostic in relation to these areas. However, WSGI also 
introduces the concept of "middleware", which are portable components 
that stack together to make or augment application frameworks. Again, 
probably best if you read the spec rather than me repeat it all here.

 >> Porting to WSGI would bring the following benefits
 >> 1. The ability to run Snakelets under any WSGI server/gateway, e.g.
 >> mod_python, CGI, BaseHTTPServer, etc, etc. (No WSGI adapters seem to
 >> exist for Twisted, Medusa or Zope though: the asynch API is still
 >> under discussion on the web-sig).
 > Users of asynch-API servers usually smile broadly when confronted with
 > worried users of 'old-skool' multiprocessing or multithreading servers.
 > It is my understanding that the latter server type (which Snakelets is
 > also a part of) doesn't scale very well to many concurrent connections.
 > If that is true, it seems to me that WSGI should somehow also provide
 > for the asynch programming style, because the "big guys" will be using
 > that one? Or am I way off here?

Ah, one of the key questions! And the answer is that, iff you write 
Snakelets according to the WSGI API, then it should be easily usable on 
asynchronous architectures. This is achieved through the use of python 
iterators (e.g. generators), so that application frameworks generate 
content on demand, when the server/gateway is ready to transmit them.

Threaded WSGI servers would maintain a pool of threads to process 
application requests, with each sitting in a loop iterating over the 
applications output, and transmitting it immediately to the client.

Asynchronous servers would maintain a pool of connections, with 
application objects corresponding to each connection. When a connection 
was ready to receive data, the server would get the next piece of data 
from the application iterator, and send it down the wire. If a 
connection was not ready to receive data, the corresponding application 
iterator would be skipped.

It will all become clearer if you read the WSGI spec.

 >> 2. The ability to factor out the need (and maintenance burden,
 >> security exposure, etc) for a custom standalone server, i.e. instead
 >> use a standard server, e.g. BaseHTTPWSGIServer, and get automatic
 >> threading or forking support, etc.
 > I'm not sure how WSGI should help me achieve this. I thought that it
 > was an API for web application builders.... not for the implementors
 > of the application server?

There are two halves to the WSGI API:

1. The server/gateway side, i.e. the bit *implements* the API.
2. The application/framework side, i.e. the bit that *uses* the API.

In relation to your custom standalone python server, it could be 
replaced by a WSGI server/gateway. The rest of Snakelets would then be 
modified to use the WSGI API, meaning that it would be portable to any 
WSGI server or gateway. There's nothing to stop you modifying the 
Snakelets standalone server so that it too implements the WSGI API. That 
means that other people could then use it as their WSGI server.

So basically, porting Snakelets to WSGI would mean splitting Snakelets 
into two parts, the server part and the framework part, with all 
communications between the two governed by WSGI. Both parts would then 
become interoperable with other WSGI components. Neat, eh?

 >> 3. Possibly run Snakelets on Java/Jython! The latter is only possible
 >> if Snakelets is 2.1 compliant, i.e. does not use python 2.2 or 2.3
 >> features.
 > Too bad, I'm using generators (amongst others) and those are unavailable
 > in Python 2.1.  I have no intentions of backporting to Python 2.1.

Oh well. Such a shame that jython is stuck at 2.1. (although a little 
impatience is beginning to surface on jython-dev).

But the upside of Snakelets using generators is that I think you will 
find that Snakelets architecture fits WSGI extremely well. Although WSGI 
supports an old-style imperative API, i.e. where input and output is 
explicitly read/written to IO channels, it is really designed so that 
applications/frameworks supply content on demand, through an iterator 
interface. Meaning that applications and frameworks should work 
seamlessly across threaded *and* event based servers. Again, this will 
become clearer on reading the WSGI spec.


alan kennedy
email alan:    

More information about the Python-list mailing list