Simon Willison wrote:
On 8 Nov 2005, at 08:47, Ian Bicking wrote:
However, I don't think you'd lose anything by routing everything through
WSGI.
IIRC, the reason Django doesn't use WSGI in the first place is that
when we first created it two years ago WSGI was still being fleshed out
on the Python Web SIG mailing list. Django's HttpRequest and
HttpResponse classes were designed to solve pretty much the same
problem as WSGI - we didn't want to code against the mod_python API (in
case it turned out not to be stable/scalable enough for our needs) so
we created our own abstraction layer to let us easily switch hosting
platforms if we needed to.
Application programmers aren't intended to program directly against
WSGI. I even ended up making a very small framework for the middleware,
since I didn't want to program the async requests against WSGI directly
(though it probably wasn't ultimately necessary; it's in
paste.evalexception.middleware.wsgiapp). The reason WSGI doesn't look
like a framework is that everyone already has their own request and
response objects, and WSGI doesn't overlap or try to take over from the
frameworks there.
That said, I personally find the Django class interfaces "fit my brain"
a lot better than WSGI does - but I can't see any reason not to use
WSGI underneath and just use a single WSGI-to-Django mapping layer
(which we already have in the WSGI handler). It would reduce the amount
of code we would have to maintain.
WSGI and Django are different things; ultimately the direct use of WSGI
should only be in the framework code itself, at which point it doesn't
look that different than mod_python, cgi, or HTTP itself. And that has
to fit in *someone's* brain! Because WSGI looks fairly similar to what
mod_python looks like already, I'm guessing the overhead should be minimal.
--
Ian Bicking / [EMAIL PROTECTED] / http://blog.ianbicking.org
