[Web-SIG] Session interface

[Phillip J. Eby]

At 12:46 PM 8/16/2005 -0500, Ian Bicking wrote:
>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.

Note that if you store state client-side (login info, for example), then 
cookie expiration is a convenient way to get the client to do your garbage 
collection.  If I want somebody's login to time out after 30 minutes of 
inactivity (or 8 hours, or whatever), the easy way to do that is to just 
set the cookie to time out, and refresh the expiration time on each hit.


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

I suppose you have a point there, in that I'd see such management as a 
useful place for a middleware plus a service.  But that's one reason why 
I'd like to see the services API spec'd out.  :)


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

Yeah, I'm just trying to point out that you keep saying "we're trying to 
solve this problem", and I say, "you know, if you do it this way, it's not 
a problem."  And then you say, "yes, but if you do it that way, then there 
are no problems for us to solve."  (i.e., it's "boring", "trivial", etc.)

At which point I say, "yes, exactly!", thinking that we now agree that it's 
silly to do things in a way that makes them into a problem.  But apparently 
you think that means we should instead spend time making problems and 
solving them, since so many other people have chosen to make their lives 
hard in that particular way.  :)

To put it another way, I see an opportunity here to educate developers 
about better ways of doing things, rather than to institutionalize wasteful 
ways of doing them.  But I realize that I'm apparently the only person who 
thinks that way, so I'll shut up now.  (At least here, anyway; in general 
I'm still going to talk about sessions being Considered Harmful from both 
the scalability and simplicity perspectives.)