[Web-SIG] Possible specs
ianb at colorstudy.com
Fri Nov 10 22:14:31 CET 2006
Ben Bangert wrote:
> On Nov 10, 2006, at 10:40 AM, Ian Bicking wrote:
>> * Ben Bangert suggested a simple session standard, focused solely
>> on the session ID (persistence handled elsewhere). This is fairly
>> but still useful.
> I'll have to find that and take a look as I no longer recall what I
> was talking about. :)
It's in the web-sig archives somewhere, I think. It was quite a while ago.
>> * Debugging mode is something that can be used in all sorts of
>> places; to increase verbosity, annotate output pages, displaying
>> 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
> I'd really like this. In addition to having a key that indicates the
> app is in debug mode, there should probably be one to indicate its in
> an automated testing mode as well for unit/function tests. The
> testing one should also provide a key where object ref's can be put
> for a WSGI unit testing harnass, like how paste.fixture's TestApp runs.
Yes, I thought about that too. It can be a good to use as a guard
against things like sending email.
I don't know if the testing variables necessarily need standardization,
but I suppose they could have it. There's no consumers right now
besides paste.fixture.TestApp. There are other frameworks that could
consume those variables, but none of them are very closely integrated
with WSGI (yet?). I don't those other frameworks have any way of
dealing with that kind of information.
>> * Request object wrapping the environment.
> I'd imagine this would be a base interface?
I'll expand on that in a separate message, as I have a fairly minimal
spec in mind.
>> * Configuration takes fairly common forms, usually a dict of some
>> sort. It could be put somewhere standard.
> Yep, should be a pretty minimal spec as well.
It's a little more vague when you have more structured configuration,
e.g., in Paste Deploy situations you have the global and local
configuration. OTOH, the common interface can be a flat dictionary,
with optional attributes for further optional structure.
>> * More user information than just REMOTE_USER; like
> I think a base spec for user information could be modeled on the user
> data information thats in the OpenID 2.0 spec. The same user keys/
> values are in the LID spec as well, modeling our environ dict for the
> wsgiorg.user_info on those spec's would make using them easy, and
> they account for all the common fields in most every auth system I've
Where in the spec are those values?
I was mostly thinking it would be a dictionary similar to the WSGI
environment, and the contents would be fairly vague. Maybe it would
have values like user_info['openid.homepage'], all of which would of
course be optional.
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG