[Web-SIG] WSGI - alternative ideas

Paul Boddie paul.boddie at ementor.no
Mon Aug 16 10:13:32 CEST 2004

> angryhicKclown at netscape.net wrote:
> Hi, I've just subscribed to this list, but I've read much of the
> Python is in dire and immediate need of WSGI.

As later messages have suggested, it isn't so much WSGI that you're
for, but a standardised API for application development.

> I think WSGI needs to be essentially very similar to jonpy
> except without the templating. Jonpy exposes an interface very similar
> Java servlets, and can run on cgi, fastcgi, and mod_python by changing
> line of code. WSGI, I believe, should be a higher-level interface than
> what has been currently outlined. For Python to succeed as a web
> (and I believe that it will), it needs to support the following out of
> box:
> - a clean servlet interface, see jonpy's Handler classes
> - support for a multitude of different platforms easily

So far, this is what WebStack [1] does. I suppose I could have either
extended jonpy or adopted the API, but I have tried to implement
which is more complete from the lowest levels upward.

> - sessions
> - database connection pooling
> - caching

Things like shared resources aren't yet supported by WebStack, but I'm
thinking of ways to expose framework functionality in a uniform fashion.

> The syntax for something like this would be as follows:
> -------------------------
> import wsgi
> class MyServlet(wsgi.Servlet): # perhaps a different name than
>     def handle(self, req, **formargs):
>         pass
> wsgi.main(MyServlet())

This is a lot like WebStack except that the initialisation of resources
(servlets in the above example) varies across frameworks. Therefore, you
wouldn't initialise resources in the same place as they are defined -
the examples for WebStack for more details.

> ------------------
> The wsgi module should automatically detect if its running under CGI,
> mod_python, fastcgi, PyWX, or even IIS ASP with Python activex script
> ISAPI. The request args are passed as key=value, unless there are
> values for one key, in which case the values are passed as a list.

See the WebStack framework support and the WebStack.Generic module for
API. I've been very conservative with the multiple values per parameter
issue, always returning a list of values whether you intended there to
just one or not, mostly because developers should be aware of such
that, if exploited by mischievous users, could make their solutions less

> The request object would support sessions via a "req.sessions" dict.
> would pick the storage method it uses depending on what platform it is
> on.

This is the general idea for WebStack's eventual session support.

> It would also support a database pool by using a "req.pool" object. I
> believe it should support pooling of any type of class. Here's an idea
> syntax:
> req.pool['database'] = (MySQLdb.connect,
>     {'user':'example','passwd':'secret','db':'example'})
> And a call to req.pool['database'] would check out a connection to
> database, and would be automatically returned at the end of the

I'm inclined to utilise a general database pooling package rather than
invent an API which in eventual hindsight could seem to be inadequate.

> Or am I taking this at too high a level? Perhaps it should simply
> the cgi module for different platforms (i.e. from wsgi import cgi,
> wsgi import mod_python), or, perhaps the wsgi module will expose the
> interface as the cgi module, and autodetect the platform and act
> accordingly.

I think you're looking at the right level for standardisation. What WSGI
meant for, as far as I've discovered through reading this list and by
occasional question, is the deployment of existing applications on top
frameworks or servers which do not natively support the API employed by
those applications; as I noted, to a Webware application running on some
WSGI layer, all frameworks and servers look like Webware.

The problem with (or rather the problem avoided by) WSGI is that it
provide any coherency for people writing applications or higher-level
frameworks - by the latter, I'm talking about things which do form
and templating - you still have to choose your favourite framework and
hope that the tricks you've employed will work on WSGI. This means that
newcomers still have to stare down that recently pruned list on the
WebProgramming page [2].


[1] http://www.python.org/pypi?%3Aaction=search&name=WebStack
[2] http://www.python.org/cgi-bin/moinmoin/WebProgramming

More information about the Web-SIG mailing list