[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