Phillip J. Eby wrote: >> SessionManager is responsible for expiration. I'm not sure what you >> are thinking of for refresh. Updating last-accessed time? That would >> be the SessionManager as well. > > > By refresh, I mean updating a cookie's expiration time.
I'm not sure; I always try to make the cookie last longer than the session can. I suppose you could store information about when the cookie is supposed to expire in the session itself (since you can't read expiration times from the cookie). Or you could store the expiration as part of the cookie data; I haven't thought about doing it that way. >> Cookies are not handled at all by these objects -- that's one of >> those boring details I think is best left to library users >> (frameworks, services, middleware), or put in another object. > > > Wow. Those boring details, as you call them, are the entire concept of > "session" to me. Now that you've posted the right interface URL, I'm > looking at it and not seeing anything there that seems related to what I > think of as sessions. OK, maybe not boring, but impossible to put in a library in any useful way. If you do put them in a library, all you've really created is a big document on possible use cases and some really boring (as in trivial) functions -- write_cookie_header(), cookie_header_tuple(), add_session_id_to_url(), read_session_id(), etc. If it built on some other standard (services, middleware, etc), then maybe it would be useful; we have no such standard, so I don't see any useful work to be done there. Instead of inventing a single-use framework to build on, or trying to tackle the larger framework standardization, I'd rather ignore the issue and assume that we attain and save the session ID elsewhere. I think most of us have a clear idea of what we want a session to be, which includes persistence; at least, that's what all the APIs discussed so far have been about, and that's what "session" means in most frameworks. It's not what you want, and that's fine -- I think if you can get a session ID and notification of events you can do what you want to do just fine, and ignore the rest. -- 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
