Home Original page

Snakelets and WSGI

Paul Boddie paul at boddie.org.uk
Wed Oct 13 06:26:01 EDT 2004 
Irmen de Jong <irmen at -nospam-remove-this-xs4all.nl> wrote in message news:<416c3fb2$0$566$e4fe514c at news.xs4all.nl>...
> Pardon my ignorance, but would it be feasible for a server such
> as Snakelets to implement both the WSGI API, *and* the existing
> 'native' API?

I suppose so. Really, as far as I understand the WSGI proposal, the
WSGI API is interesting mostly for plugging existing frameworks and
servers into various server technologies. Having the Snakelets server
expose the WSGI API isn't particularly interesting for application
developers in itself, but it would allow someone to run a Webware
environment on top, for example.

Now, running a *complete* Webware environment on top of the *complete*
Snakelets environment may be of questionable benefit, but the
rationale behind WSGI is that you'll eventually separate the actual
server code from the framework code, expose the WSGI API from your
server code, and have your framework code use that API when it deals
with HTTP communication. Ultimately, it's claimed that all the
different frameworks and servers will be interoperable - applications
using Snakelets, Webware and other WSGI-dependent frameworks will run
on the Snakelets server and other WSGI-compliant servers.

It has been said that various people are looking into supporting WSGI
in their frameworks, but that obviously still leaves the whole matter
of framework-level standardisation out of the picture. My small
contribution on that front is the WebStack package which provides a
common API for a number of the more popular frameworks and
technologies:

http://www.python.org/pypi?%3Aaction=search&name=WebStack

Of course, WebStack support for WSGI could potentially be implemented,
too, but for now the only practical way to deploy cross-framework
applications is to use one of the framework-specific adapters provided
by WebStack. Perhaps only a WSGI adapter will ever be needed in the
distant future, however.

Paul
More information about the Python-list mailing list