[Web-SIG] Session interface

Ian Bicking ianb at colorstudy.com
Tue Aug 16 19:46:49 CEST 2005


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  /  ianb at colorstudy.com  /  http://blog.ianbicking.org


More information about the Web-SIG mailing list