Ian Bicking: the old part of his blog

Re: WSGI and Dispatch

Thanks for clearing up my failed attempt at Python; I've only dabbled with it.

You're right that this was partly inspired by Servlets, but only insofar as I consider them to be a pretty good API for HTTP that I've used successfully for a number of years. You can use Servlets as you would use WSGI, by just overriding the service() method, or you can use doGet, doPost, etc.. URI based dispatch can either be handled within service(), or using any of the URI-dispatching tools the containers typically provide (e.g. web.xml). So there's certainly ample precedent for this form of API supporting the flexibility WSGI seems to require. But only doing the equivalent of service() (as WSGI currently does) places more of the burden on remaining HTTP-friendly with what's built on top. Perhaps that will work out, I don't know, but I don't see much downside to such a framework constraining the use of HTTP as I've described. But if it doesn't work out for WSGI, and you have apps which, for example, don't distingiush GET and POST, then you lose the ability to, say, support cache management at the WSGI level. Providing a Servlet-like API doesn't guarantee you that HTTP won't be abused of course, but it does reduce the likelihood that it'll be done accidentally.

Comment on WSGI and Dispatch
by Mark Baker

Comments:

Mark, not much people will wirte apps directly to the WSGI layer, but instead they'll use some framework... or at least will use some simple tool (like the 'selector' wsgi dispatch - http://lukearno.com/projects/selector/).

# Damjan