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

[Irmen de Jong]

I'm happy to say that Snakelets 1.35 is available.

Snakelets is a very simple-to-use Python web application server.
This project provides a built-in threaded web server (so you don't
need to set up Apache or another web server), Ypages (HTML+Python
language, similar to Java's JSPs) and Snakelets: code-centric page
request handlers (similar to Java's Servlets).
Snakelets is fully unicode compatible and it's possible to run it
from a CD (read-only mode).

It's released under the open-source MIT Software license.

You can download from http://snakelets.sourceforge.net
(go to the SF project site, and then the file section).

Recent changes include:

* IMPORTANT: privileges are now also checked when using HTTP auth methods
* various documentation improvements and spelling corrections
* LoginPage base class improvements
* Ypage compiler improvements
* general bug fixes
* fixed the http-gzip-compressor plugin (separate download)


To start, edit the vhost config file (see docs) and
then run the serv.py script, or the monitor.py script
if you want to start it as a daemon (on Unix).

Enjoy,
--Irmen de Jong.


P.S. if you want to see it in action, visit www.promozilla.nl
(the site is in Dutch though)

 

[Alan Kennedy]

[Irmen de Jong]

I'm happy to say that Snakelets 1.35 is available.

Snakelets is a very simple-to-use Python web application server.
This project provides a built-in threaded web server (so you don't
need to set up Apache or another web server), Ypages (HTML+Python
language, similar to Java's JSPs) and Snakelets: code-centric page
request handlers (similar to Java's Servlets).
Snakelets is fully unicode compatible and it's possible to run it
from a CD (read-only mode).

It's released under the open-source MIT Software license.

You can download from http://snakelets.sourceforge.net
(go to the SF project site, and then the file section).

Irmen,

Thanks for your all your great work on Snakelets.

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.

http://www.python.org/peps/pep-0333.html

WSGI specifies a HTTP API which is implementable on most conceivable web
platforms. Code built on this API is fully portable to

1. All WSGI compliant "servers", i.e. pure python WSGI servers.
2. ALL WSGI "gateways", i.e. other non-python servers for which a python
WSGI layer has been developed.

WSGI is an excellent piece of work, by a fine designer, Phillip J. Eby,
of PEAK and PyProtocols fame.

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).

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.

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.

4. Immediately be able run Snakelets on IronPython when it becomes
available, and a when (very simple!) WSGI gateway layer has been written
for whatever web servers can run .Net web applications. This support
would come for free: ideally, no modification to Snakelets would be needed.

You could currently run Snakelets on java with modjy, an open-source
WSGI compliant gateway I've written on top of J2EE servlets. Docs,
details and downloads here

http://www.xhaus.com/modjy

I have high hopes for WSGI to help simplify the confusing landscape of
server platforms upon which python web frameworks can and cannot run.
IMHO, portability of python web application frameworks to all possible
web servers, pure python or not, should be an inherent out-of-the-box
capability, not an exercise in code engineering.

kind regards,

 

[Irmen de Jong]

Irmen,

Thanks for your all your great work on Snakelets.

You're welcome, it's been a pleasure to do so

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.

http://www.python.org/peps/pep-0333.html

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.

Disclaimer for the next few questions: I haven't yet read PEP-333.

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

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?

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?

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.

I have high hopes for WSGI to help simplify the confusing landscape of
server platforms upon which python web frameworks can and cannot run.

It certainly sounds promising.


Cheers!
--Irmen.

 

[Alan Kennedy]

[Alan Kennedy]
[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.

>
> 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.

>
>
> 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?

>
>
> 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.

regards,

 

[Irmen de Jong]

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.

Interesting idea. I haven't thought about generating output this way.

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

Will do

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?

Sounds neat, but I think this is a hard thing to do for me.
Anyway we'll see. First have to read the WSGI doc thoroughly.

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.

Hm, that's not what I meant by "using generators". I'm using them
for other things, but not the generation of output...

Thanks for answering my questions.

off-to-read-the-WSGI'ly yours,
Irmen.