[Web-SIG] WSGI - alternative ideas

[Paul Boddie]

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

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

> I think WSGI needs to be essentially very similar to jonpy
(jonpy.sf.net),
> except without the templating. Jonpy exposes an interface very similar
to
> Java servlets, and can run on cgi, fastcgi, and mod_python by changing
one
> 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
language
> (and I believe that it will), it needs to support the following out of
the
> 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
something
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
Servlet?
>     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 -
see
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
or
> ISAPI. The request args are passed as key=value, unless there are
multiple
> 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
the
API. I've been very conservative with the multiple values per parameter
issue, always returning a list of values whether you intended there to
be
just one or not, mostly because developers should be aware of such
issues
that, if exploited by mischievous users, could make their solutions less
robust.

> The request object would support sessions via a "req.sessions" dict.
WSGI
> would pick the storage method it uses depending on what platform it is
run
> 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
for
> 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
that
> database, and would be automatically returned at the end of the
request.

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
clone
> the cgi module for different platforms (i.e. from wsgi import cgi,
from
> wsgi import mod_python), or, perhaps the wsgi module will expose the
same
> 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
is
meant for, as far as I've discovered through reading this list and by
the
occasional question, is the deployment of existing applications on top
of
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
doesn't
provide any coherency for people writing applications or higher-level
frameworks - by the latter, I'm talking about things which do form
handling
and templating - you still have to choose your favourite framework and
then
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].

Paul

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