[Web-SIG] Possible specs
Ian Bicking
ianb at colorstudy.com
Mon Nov 13 21:31:16 CET 2006
Robert Brewer wrote:
> Ian Bicking 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.
> > ...
>
> and Luke Arno replied:
>
> > 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.
>
> I absolutely agree. Web development (at least in Python) is moving *way*
> too fast for this to be a good time to introduce lots of specifications.
Even if they are really really small?
> Sessions have 1) been around forever, 2) have consistently been done
> similarly for each implementation, and 3) already require interoperation
> with third party code (database APIs), so introducing a common interface
> would not introduce any overhead. Therefore, session handling would be
> the only candidate I see for standardization.
I don't have any problem with standardizing this, but I don't think it's
particularly useful to share sessions across applications. It's useful
to share configuration and backend setup, and probably good to share the
session tracking policy. The actual contents of sessions are largely
private to the application. But that can also be handled as an aspect
of deployment, so whatever.
Here's Ben's session ID proposal:
http://mail.python.org/pipermail/web-sig/2006-January/001858.html
Here's an interface I proposed last year for sessions:
http://svn.colorstudy.com/home/ianb/proposed_session_interface.py
It's not that simple of an interface :(
> All the other proposals seem like ways to work around the weaknesses of
> WSGI by promoting lowest-common denominator agreements, and, since most
> consumers of WSGI have by now already worked around those weaknesses in
> ways that natively fit their code, any specification at this point would
> only introduce interface overhead into those codebases. The last thing
> I, as a framework dev, want to provide/require of my users is yet
> another point of composition. Let's standardize those points which
> already _require_ composition (like sessions), and worry about those
> points which merely _allow_ composition at a later date.
While I don't have a problem with a session standard, I don't think
sessions require or even benefit from composition. Authentication
definitely does, but we have some light agreements on that. We could
probably build a very conservative specification for authentication that
makes explicit some things that are inherited from CGI.
--
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org
More information about the Web-SIG
mailing list