[Web-SIG] Updated my WSGI examples

[Ian Bicking]

Phillip J. Eby wrote:
> Good, then I won't feel so bad about telling you that the 'wsgi.' prefix 
> is reserved for WSGI-defined features, so "wsgi.field_storage" and 
> friends are right out.  ;)
> 
> Technically, I think this was only implied in the spec, not explicitly 
> stated, so I'll have to fix that.  Anyway, the idea of the prefix is to 
> avoid name collisions between different developers, so you need to pick 
> your *own* prefix that isn't the same as anybody else's.

That raises a question of convention that I was thinking about.  I ended 
up giving each of my modules its own namespace.  Which probably isn't 
the right way to go.  But then, I also wasn't trying to think of them as 
a unified package.  Also, some of the extensions are meant to be opaque 
to the rest of the application; for instance, a cookie parser stores 
data in the environment to cache the parse, but that data shouldn't be 
manipulated by other applications.  Maybe I should have used a leading 
underscore.

Also, there's already things I'm starting to think of in terms of 
extensions, where we'd agree on the meaning of a second namespace.  For 
instance, I'd like a flag to indicate to applications that they should 
let their unexpected exceptions be raised.  This would be nice for 
something like a debugging server that can be run in a console and falls 
into pdb when there's an error.  Once this flag was set, middleware 
further up shouldn't catch unexpected errors; and if this flag isn't 
set, then applications should avoid letting errors escape.  Sessions and 
configuration might be other places where standardization is called for, 
just to think of some things I've encountered so far.

But then, this should probably be part of a second standard, which 
follows from WSGI.  Maybe WAI, Web Application Interface, to make up an 
acronym.  Or maybe "webapp" would be better.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org