[Seaside-dev] expiry policies

[Julian Fitzell]

On Fri, Sep 19, 2008 at 7:14 AM, Julian Fitzell <jfitzell at gmail.com> wrote:
> On Fri, Sep 19, 2008 at 1:54 AM, Ramon Leon <ramon.leon at allresnet.com> wrote:
>>> I haven't seen the code, but as a use case, I'd like
>>> to be able to say:
>>>
>>>    self session expireInNoLessThanSeconds: (86400 * 7).
>>>
>>> to make a particular session have a long expiry, if it
>>> contains a callback URL
>>> to validate a user or something.  I don't think there's an easy way
>>> to decide expiry on a per-session basis.
>>>
>>> --
>>> Randal L. Schwartz - Stonehenge Consulting Services, Inc. -
>>
>> You can do that now fairly easily...
>>
>> self session timeoutSeconds: (86400 * 7).
>>
>> I haven't seen 2.9, but that works in 2.8, I change my session timeout
>> dynamically when I detect an ajax request to kick up the timeout because
>> that tells me it's a real user and not a spider.
>
> Well, I'll have just broken that in this code. But I'll ponder the
> best way to continue supporting it...
>
> The question is how you should interface with the cache when its
> strategies are pluggable...

So, I don't quite have an answer yet but I had some thoughts during
the day today that I thought I would share in case they prompt further
thoughts from someone else.

It occurs to me that there are two different concepts of expiry here.
One is (a)"can I access the session or has it expired?" and the other
is (b)"is the session stored in the cache or has the cache expired
it?".  Obviously the two are related (if it's not in the cache, you
can't access it) but they're not quite the same.

You could implement all kinds of funky per-session expiry policies of
type (a) by using the new RequestFilters and attaching them to the
session. This obviously depends on the cache keeping your session
around long enough, though.

You might get away with a suitably long cache expiry time, but I think
I will also change the expiry policies so they receive both the object
and the key. That way you could write a policy that depended on having
stored objects with a particular interface and you could use that to
ask the object for details such as the length of time it would like to
remain alive. That might at least give the flexibility to implement
such a system, even if it ended up seeming too hardcoded to provide
out of the box.

Julian