[Web-SIG] Possible specs

[Luke Arno]

On 11/10/06, Ian Bicking <ianb at colorstudy.com> wrote:
> Luke Arno wrote:
> > 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.
>
> This is a straight copy of the wiki, I haven't written anything up on
> any of these beyond what you see here.

Ah, I see.

> >>      * 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.
>
> Since it is backend/persistence-neutral, it's up the app to figure out
> how to consume it; there could be multiple sessions for a given ID, or
> not.  This just gives you a stable ID.  It should probably be created on
> demand, as if you don't care about the session you shouldn't be
> generating a session ID (and cookie to go with).
>
>
> >>      * 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?)
>
> This is more-or-less what paste.session does.  It might be a little too
> minimal, though.  For instance, there's no way to distinguish between
> read-only access and read-write access; hence no way to do locking or
> serialization (without adding some real concurrency problems), and no
> way to avoid rewriting the session on every request in case some
> contents have been changed.
>
>
> >>      * 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?
>
> I often do a bunch of stuff in debugging mode that is more aggressive
> than just log_level, and shouldn't be done at all in normal mode.  So a
> real on-off switch for debugging is useful.

I expect your development (like mine) is a little atypical.
I am often working on various parts of the stack at the
same time. Most web developers are just working on
an app and would not like to see debugging info start
pouring out of everything under it. That is probably not
what you are suggesting. Still, I think that this is a low
value target for community standardization (though for
an individual who is all over the stack, it is a great
personal convention.)

> >>      * 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?
>
> Sometimes there's multiple pieces of middleware.  For instance, I might
> have one on the outside, with another one in a subapplication (which is
> independently deployable, so needs some kind of wrapper).  Also it is
> needed to avoid catching errors when running tests, where you want the
> exception to go up all the way to your test runner (which might have a
> debugger or special traceback formatter).

This is probably just not relevant to my development
style. Or maybe I just don't get it.

>
> >>      * 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.
>
> I'm not really sure here, myself.  I know people ask for it, and
> sometimes I'm pretty sure I want something like this, but I don't feel
> very solid about what best practice in logging is.  I couldn't write
> this one.

I am with you. I create loggers for their respective
scopes and call them as needed. Log levels go in
a config and that is the whole story. What else?

I think people sometimes ask for structure because
they are unsure when all they need is to go for it.

> >>      * 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. :)
>
> Thread local stuff can be a pain; I often curse it.  I think it can be
> okay with the right patterns.

If we codify it, I think it will be used. A lot.

I recently looked over a sort of a contact manager app
for somebody. There were metaclasses all over the
place. :)

> >>      * 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?
>
> No, not at all, there's no base class (not even an optional base class).

Sorry, I was thinking of Paste Script. I can't keep it
all straight sometimes. ;)

> The interface for apps is basically:
>
>    def app_factory(global_conf, **app_conf):
>        return wsgi app
>
> It's pretty neutral, with some notable details:
>
> - global_conf is basically inherited configuration.  It may or may not
> apply to this application.  The application factory can ignore it or not
> as it sees fit.  app_conf is definitely intended for this application;
> you can do more strict checking on it, make sure there's no extra values
> or that certain required values are present, etc.
>
> - all values can be strings, and strings should be handled specially.
> That is, if you expect an integer and you get a string, you should
> coerce it to an integer.  If you expect a list and you get a string, you
> should probably split the string in some fashion, or just turn it into a
> one-item list.  If you expect a boolean and you get a string, you should
> convert it intelligently (not based on the truth/falsiness of the string
> itself).
>
>
> That's it.  Middleware and servers have similar interfaces.  The server
> interface is a little under-powered (it just serves a WSGI application
> forever); it could be extended some, or left unspecified for now.
> Middleware takes as a first argument the application being wrapped.  Oh,
> and composites, which are a little harder -- they take as a first
> argument an object that can load more WSGI apps.  That's used for
> dispatchers that can direct to multiple subapplications.  That's more
> tightly coupled with Paste Deploy's app naming conventions, and it might
> be better to put explicit app loading into the configuration format and
> pass them in as keyword arguments to the dispatching app.

This is all a bit meta for me. I guess I don't get it. :)

> >>      * 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.
>
> WSGI isn't all that complex, but validation is very helpful when people
> get it wrong.  It should be useful for any of these specs as well.  It
> also makes the spec much more explicitly clear, because computers check
> things more reliably than humans ;)

I am not arguing against validation. I am just hoping
that it's superfluous in the near term.

> >>      * 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?
>
> Originally it was to support internal redirects and inclusion (which
> were part of the Webware API).  Now I find it useful for doing internal
> subrequests when using web-based APIs.

That makes more sense. I have some forwarding
stuff like that in YARO because it can be used
to hide the WSGI interface a little. Other than that
I just call the thing I want to forward to. (I don't
like to use exceptions for normal flow control very
much, though it does come up.)

Either way, finding what to forward to is the trick,
which is dispatch, and there are a whole lot of
ways to skin that cat.

> >>      * A place to put a database transaction manager
> >
> > -1 Way too specific.
>
> There'd have to be a database transaction manager standard first, anyway.

I admire your ambition. :)

> >>      * 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?
>
> This shouldn't be a real user object, more likely a dictionary, just
> like the WSGI request is a dictionary (environ) and not an object.
> Objects are hard to standardize ;)

They are. I would be interested in this though I
remain somewhat skeptical.

> > 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.
>
> Most of them are taken from keys already in Paste (or in a couple cases,
> that I wish were in Paste but have been lazy about adding).

This is exactly my point. You have made a big impact
with Paste because it is very pioneering. While that is
very commendable, I would like to see things play out
on a wider stage before they get standardized.

> > Sessions *might* be doable.
>
> Possibly; but sessions don't personally interest me a whole lot.  It
> wouldn't be my first choice to write up, but if someone else writes it
> up then great ;)

Yeah it is sort of boring but could simplify interop
and is a pretty well understood thing. I'm not
volunteering, of course. ;) Maybe, if I find time.

I feel like a total wet blanket right now but I hope
it is useful.

Cheers,
- Luke