[Seaside-dev] expiry policies

[Philippe Marschall]

2008/9/19, Julian Fitzell <jfitzell at gmail.com>:
> 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.

Some more random thoughts. I first though that implementing issue 110
would need an additional dimension. The idea behind issue 110 is that
once a given amount of sessions is reached, no new sessions are
created. But now I think that it could be implemented by simply adding
sessions that are already expired. Since session creation in Seaside
is rather cheap this should not result in a big overhead.

Cheers
Philippe