2006/10/18
-
Hmm, I like the idea of a common substrate for Python Web apps, like Servlets provides for Java. But a *gateway* interface for doing it? Ack. IMO, that layer needs to reflect HTTP to the upper layers properly, as Servlets do.
-
A funny name for an application protocol which tramples over HTTP by confusing it with a session layer protocol. Doh.
-
RFC 2616 + errata + reference updates
Re: WSGI — is there something in particular you see as a problem? I’m not sure what the issue with “gateway” is, but mostly because I’m not sure what you are reading into that term. WSGI is a gateway from HTTP to a Python function call, I guess; it tries to represent HTTP as accurately as possible/necessary (e.g., Keep-Alive is handled above WSGI, so it isn’t part of the interface).
Ian – what I mean by “gateway” is the same as the “G” in “CGI”; a lossy interface to the thing behind the gateway, in this case a lossy interface to HTTP. This is the problem;
“def application(environ, start_response):”
Because it encourages bad practice with HTTP, such as those apps that behave the same way to GET and POST requests (as the examples in the article do).
I think this would have been superior;
def get(environ, start_response):
def post(environ, start_response):
def put(environ, start_response):
etc..
You can build things like you want on top of WSGI. Joe Gregorio’s collection class is a good example: http://bitworking.org/news/wsgicollection
But it would have been entirely wrong to build method-based dispatch into the interface. It would have been wrong to build *any* kind of dispatch into WSGI. Really what you are describing is dispatch to functions based on the request method. But usually you start out by dispatching based on the request path, until you “find” the thing being acted on, and then you pass the request on to that object. The thing being acted on may very well itself start another dispatching process, and so forth. E.g., a typical request might involve dispatch based on the Host header (virtual hosting), dispatch to a particular application/library based on the path prefix (i.e., delegating chunks of the URI space to different software), then a more complicated pattern-matching system that actual instantiates an object, does validation (e.g., if there’s a date encoded into the request path), and then *that* object might actually do something besides dispatch. Each of those levels of dispatching can use WSGI, as the request is extensible enough to annotate it with the intermediate information.