[Web-SIG] ANN: Release 0.20.0 of modjy: a WSGI gateway for jython
2.1 and J2EE.
Ian Bicking
ianb at colorstudy.com
Mon Oct 4 04:54:13 CEST 2004
Phillip J. Eby wrote:
>> Also, I would have to add a fair amount of extra code, just to ensure
>> that the extension APIs present the same information as the standard
>> WSGI interface. Which seems unnecessary, given that the WSGI
>> information is already there.
>
>
> Right. I think it's a natural first thought to say, "Oh, I'll add an
> extension API so you can get at the original server request", but given
> the purpose of WSGI, at second thought it seems rather pointless. If
> the app author wanted something non-portable, he'd have written to the
> server's API to begin with. If it's *extra* information you're
> providing, just add it to environ, as long as it's not information
> *derived* from other data in environ. If it's derived, offer a function
> to derive it, rather than data.
I think Alan might be considering a situation in which there's some
information which he isn't aware of that's missing, and rather than have
the application author curse him for neutering his environment, he gives
the author a way to get around it all.
Then, ideally, the author makes a note of this and the information shows
up in the next version of modjy. Or, the author who uses that
information just has to be careful about data integrity him or herself.
Maybe it would be sufficient not to provide the request or response
immediately in the dictionary, but require the author to do something
like j2ee_req = environ['modjy.request'](environ); then when they get
this, you could emit a warning, or if they get the request and you
detect that there's something weird about the environ, you return None,
raise an exception, log a warning, or something along those lines.
--
Ian Bicking / ianb at colorstudy.com / http://blog.ianbicking.org
More information about the Web-SIG
mailing list