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. _______________________________________________ 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