[Seaside-dev] expiry policies

Julian Fitzell jfitzell at gmail.com
Thu Sep 18 10:59:02 UTC 2008


On Thu, Sep 18, 2008 at 8:19 AM, Philippe Marschall
<philippe.marschall at gmail.com> wrote:
> 2008/9/17 Julian Fitzell <jfitzell at gmail.com>:
>>> Why do we have that in the policy which might or might not be a
>>> WAExpiredExpiryHandler? Why not in the response factory?
>>
>> Well, I thought that the policy might want to give a more detailed
>> error message about why it had expired and so on. But perhaps that is
>> misguided... I don't feel strongly about it and could certainly put it
>> back to "self responseFactory pageExpiredFor: aRequestContext".
>
> I think you'll rather have an application specific error with the look
> and feel of your application.

Yeah, fair enough. I removed this code.

Thinking about this some more, though, it occurs to me that in order
to implement expiry policies like "no more than 100 sessions" the
expiry policy needs to be external to the handler that is being
expired. I'm not quite sure what the design for that would look like
though, nor whether we need to support such things.

The code for WARegistry is a bit ugly at the moment. Maybe a good
design would be to clean it up, provide pluggable expiry policies
there, and make it therefore capable of storing *any* kind of request
handler?

Julian


More information about the seaside-dev mailing list