ANN: Snakelets 1.35 (simple-to-use web app server with dynamic pages)
alanmk at hotmail.com
Tue Oct 12 08:11:07 EDT 2004
>> 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
> 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.
email alan: http://xhaus.com/contact/alan
More information about the Python-list