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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
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
