[Web-SIG] Possible specs

[Ian Bicking]

I brainstormed some ideas for wsgiorg specs and added them to the spec 
page, and also copied here.  I offer them here to see if there's 
particular specifications that seem interesting, and might be worth 
pursuing sooner than other ones.


     * Ben Bangert suggested a simple session standard, focused solely 
on the session ID (persistence handled elsewhere). This is fairly modest 
but still useful.

     * Maybe a full session interface built on the session ID standard.

     * Often debugging tools open security holes (for example, 
paste.evalexception gives you a Python prompt on every exception). 
Authentication isn't really the right way to handle it, because 
debugging might involve logging in as various users. A specification 
could just define a key that indicates when these debugging tools should 
be allowed. This might get set by configuration, IP address, a cookie, etc.

     * Debugging mode is something that can be used in all sorts of 
places; to increase verbosity, annotate output pages, displaying errors 
in the browser, etc. Having a single key for turning on debugging mode 
would allow its consumption in lots of places. Not as strict as 
authenticating.

     * Some systems prefer that unexpected exceptions bubble up, like 
test frameworks. A key could define this case (modelled on 
paste.throw_errors) and thus disable exception catchers.

     * Logging is a tricky situation. The logging module allows for 
statically setting up logging systems, then configuring them at startup. 
This often isn't the best way to set up logging. Putting a 
logging.Logger instance right in the environment might be better. This 
requires some design and usage before setting on one spec.

     * Request object wrapping the environment.

     * Thread-local values are a common technique in web frameworks, 
allowing global objects or functions to return request-specific 
information. This pattern could be codified into one core system, using 
some feedback from existing systems (which have their advantages and flaws).

     * Configuration takes fairly common forms, usually a dict of some 
sort. It could be put somewhere standard.

     * Maybe Paste Deploy's entry points could be standardized. (Paste 
Deploy itself only consumes those entry points; other consumers are 
possible and packages implementing those entry points don't introduce 
any dependency on Paste Deploy)

     * A way to extend wsgiref.validate to add more validation, for all 
these new specs. (Probably this is an implementation, not a spec)

     * A way to describe custom keys, maybe associated with the validation.

     * Anchors for doing recursive calls, similar to paste.recursive. 
(paste.recursive is kind of an old module that is more complicated than 
it needs to be)

     * A place to put a database transaction manager

     * More user information than just REMOTE_USER; like wsgiorg.user_info?

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