[Web-SIG] and now for something completely different!
Phillip J. Eby
pje at telecommunity.com
Thu Aug 18 04:51:35 CEST 2005
At 09:16 PM 8/17/2005 -0500, Ian Bicking wrote:
>Phillip J. Eby wrote:
>>The reason it's How Things Are in Java-land is because Java made sessions
>>part of their servlet and other specs right from the start -- a serious
>>error that I was hoping we could avoid in Python-land.
>Too late; all the major (and even all the minor) Python web programming
>environments have sessions.
I seem to recall that it's part of the Java servlets *specification*,
whereas we did manage to avoid that trap in WSGI. :)
>>At least PHP gives you session management hooks that make it easy to put
>>session data in the application database!
>That shouldn't be hard here either.
Yep. That's why I was pushing for standardizing that part separately from
any actual storage facility, and for having good ways of managing the
client-side state, which every "session" facility needs.
If client-side state management turns out to be more library than framework
or spec, so be it; we can nominate it for stdlib inclusion in 2.5, and it's
one less thing for people to think about. "Boring" in this case is a good
thing, it means we have a solved problem. :)
What I *don't* want to standardize is the "bag of persistent objects"
session interface as the primary way of accessing session data; I'd rather
make the client key <-> retrieval aspect explicit, so that it's clear that
you can totally choose how that links up, e.g.:
session_id = get_client_state(env, 'session.id', new_hook, timeout_hook)
my_bag_of_junk = session_store[session_id]
To put it another way: I'd like to distinguish "session variables"
(client-side values) from "session objects" (server-side objects), and make
the boundary between them very clear in the API. That doesn't mean a
session store can't offer a shortcut API, but hopefully the standardization
of session object stores is *in terms of* the session variables API, so
that e.g. the callbacks you need are the same, you still specify somewhere
what session variable you'll use, etc.
Note too that focusing our effort at this API level lets us address
"interesting" problems such as when redirection is needed to start a
session, when we need to replace page content to notify that a session has
timed out, etc. These are all client-state management problems and nothing
to do with the persistence question, but are more interesting problems to
solve (IMO) than re-solving the same old object persistence problems over
and over again.
More information about the Web-SIG