[Web-SIG] and now for something completely different!

[Phillip J. Eby]

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.