At the risk of showing my ignorance concerning WSGI, it's easier to use a session library in Perl than a session library in WSGI, because the session library has no knowledge of anything in your application, not even a context object.
I don't understand why you think WSGI requires anything different.
Actually, most of the time I wonder why people think sessions should be implemented with WSGI middleware at all, as opposed to just using a library. Each time, however, I eventually figure out that it's because they'd like responses affecting the session (e.g. Set-Cookie headers) to be done automatically, without the app needing to care about it.
Of course, management of the "session state" vs. management of the "session content" are largely orthogonal concerns that might be worth standardizing an interface between, so that you can mix and match session-state mechanisms (cookies, subdomains, paths, query string tags) with session-content mechanisms (files, database, shared memory, etc.).
_______________________________________________ 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
