[Web-SIG] Possible specs

[Luke Arno]

On 11/10/06, Ian Bicking <ianb at colorstudy.com> wrote:
> 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.

Wow. This is a tidal wave. :)

I haven't had a chance to read on the wiki but I will
comment on the short descriptions.

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

Maybe. Pick a key. wsgiorg.session_id?

Does anyone use more than one session at a
time? I don't, but it seems wise to ask.

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

Maybe.

I favor the dict interface. Must be lazy-loadable.

wsgiorg.session_loader = callable that takes environ
wsgiorg.session = cached dict like object

We need a method to invalidate (on the dict-like?)

...

>      * 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.

I don't care because I don't use anything like that.
(Nor do I want to.)

>      * 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.

Maybe.

wsgiorg.log_level? If you change the log level,
do you want this to effect the whole stack or
just your own stuff?

>      * 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.

-1 I don't need it. Too abstract.

Usually, you just have one error handling
middleware on the outside of the rest, no?

>      * 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.

Maybe a lazy logger loader that takes the level
as an argument? Seems a little silly.

>      * Request object wrapping the environment.

I use YARO request objects for this and it works
out well. Do we need a standard? What if different
middleware authors prefer different request objects?
If they are competing for the same environ key that
is not good.

I had a long email conversation with someone who
wanted to push for YARO to become standard but
I am just not sure that makes sense.

>      * 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).

-1 but I don't like using thread locals for such things.
    Save the magic for things that need it. :)

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

-1 Different components may need different configs.
    I have seen class instances and modules, not
    just dictionaries.

>      * 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)

-1 We would have to conform to your ABC
    to make use of this, right?

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

That makes sense if our standards are that involved.
I don't see standardizable clarity on much that is so
complex.

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

Same.

>      * 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)

Is that really such a common pattern? It is clever
but I have yet to find a case for it. Maybe I am just
overlooking something. What do you usually use
that for?

>      * A place to put a database transaction manager

-1 Way too specific.

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

User objects are like request objects and I don't see
what we gain from making them fight for a key.

Could this actually decrease real interop?


I am worried that things are getting a little inventive
here. This is how things get heavy. Lets try to stick
to codifying those things that have a clear common
right way. Most of these don't meet that, in my
opinion. Pursuing many of these will lead to endless
arguments as they are just unproven which means
we should just let the diversity simmer for a while.

Sessions *might* be doable.

IMHO, YMMV, ...

Cheers,
- Luke