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 | [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
