> >> I'd personally love to see a common set of request/response/session
> >> objects (a la Paul's webstack) be adopted.
> > Isn't that what WSGI offers?
> Perhaps I need to look closer but my assumption after a pass through
> the PIP a while ago was that it was more of standard way of
> getting the information to and from the framework ("middleware") and
> likely not meant to reach the presentation and controllerish code.
Hmm. My mistake. I suppose I've been living in Java-land too long,
and reading my viewpoint from there into other projects.
Although, in my defence, PJE seems to say here:
http://mail.python.org/pipermail/web-sig/2004-August/000668.html
that once WSGI is a little more commonplace, it'll be easier to look
at other places of duplicated functionality, and extract them out.
Perhaps we'll have WSGI-Session, WSGI-Request/Response, WSGI-etc...
It seems that we might already be moving that way, with stuff like
WSGI Utils - http://www.owlfish.com/software/wsgiutils/
> I'd love to find out that I'm wrong, although I guess I would
> find the WSGI idioms around accessing request headers/form-encoded
> data and collecting response information a bit cumbersome compared
> to the APIs provided by Webstack, Quixote, Webware, CherryPy, etc.
Is there any commonality between those APIs? I'm sure people would
be more than happy to conform to a standard API, especially if the
source for the adapter was provided... It could possibly even make
it into the WSGI PEP, if enough people found it useful.
(Just reading through the PEP a little, I see the lines:
> Why is this interface so low-level? I want feature X! (e.g. cookies,
> sessions, persistence, ...)
>
> This isn't Yet Another Python Web Framework. It's just a way for
> frameworks to talk to web servers, and vice versa. If you want these
> features, you need to pick a web framework that provides the features
> you want. And if that framework lets you create a WSGI application,
> you should be able to run it in most WSGI-supporting servers. Also,
> some WSGI servers may offer additional services via objects provided
> in their environ dictionary; see the applicable server documentation
> for details. (Of course, applications that use such extensions will
> not be portable to other WSGI-based servers.)
And what that says to me is: "If you want these features, don't use
WSGI.", which is sort of strange, since WSGI could provide a reasonable
API (or even just _an_ API) that applications could use to give
themselves a modicum of framework-independance.
Reading over this a little more, I think I might just have a completely
wrong idea of what WSGI is, and where it's applicable, but having said
that, given the plethora of frameworks out there, having something that
webapp developers can code to to allow them to run unchanged on a few
different frameworks (even if they have limited functionality) seems
like a good idea. Is that the purpose behind WSGI, or is it the layer
below, where frameworks talk to servers?
Later,
Blake.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
