[Bese-devel] expired sessions

[Marco Baringer]

<with-thinking-out-loud>

i don't remeber where i've talked about this issue and where i
haven't, if i'm repeating myself just ignore me.

what happens when the user's session expires? on the server we simply
remove a hash-table entry which frees up all the data associated with
that session. on the client side however nothing changes, the page is
still there and the links are still clickable, and this is the
problem, what happens when we get a request for a session which
doesn't exist anymore?

decisions, decisions, decisions.

there are a few options:

1) don't expire the session, or expire it after a very long time of
   inactivity. this is actually a fine solution on internal systems
   with just a few (< 50) users where the number of sessions is never
   greater than a few thousand.

2) expire the last frame of a session after a very long time. this
   seemed like a good idea, and does in fact catch 95% of the issues
   without uselessly consuming lots of memory, but it's a half-assed
   hack which i'm not going to implement.

3) make the url's generated by action-href usefull even if the session
   has expired. generally these urls look like
   .../ucw-action-call.ucw?f=...&s=...&a=... (forms set f, s and a via
   hidden parameters, but the idea is the same). the idea would be to
   make the ucw-action-call.ucw flexible enough so that a developer
   could set things in such a way that a meaningfull entry point url
   would be generated. these may not be exactly what the user expects,
   but would be far better than the current situation.

option 3 looks best, but i'm not really sure what the interface should
be. there are quite a few entites which may want to say what that url
should be: the application, the session, the session frames and the
component rendering the link. obviously we would like the application
be able to provide a default (probably to a home page or some such)
but we'd also like the session ta have it's say so "My" type pages
would work and the component could be usefull so that we can provide
links which have something to do with what the intended action
was. then we need to decide how this is set and how entry-point
parameters interact with it.

idea 1 is that "it" will be a generic function where the first of
component, current session frame, session or application (in that
order) to supply a value will be used. the function would be passed
the current object and the current context, which should be enough to
generate a usefull url.

idea 2 is make "it" the value of a slot in standard-component,
standard-session-frame, etc. (as opposed to a generic function) with a
function which reads from the various slots. this would allow you to
set up different urls without having to sub class too many things, but
would make putting parameters in the urls more difficult. 

both of these ideas don't play well with nested components. for
example: if we have a range-view located in some result set, we'd like
to make the urls gerented by the range-view go to the result object's
query page (or recreate the query and directly show the results via
parameters to an entry point). neither of the above ideas make this
use-case particularly easy or clean (maybe this is a case where you'd
use something from the session-frame, then then you're limited to one
entry point url per page, which goes against ucw's components are
independent philosophy).

i'd appreciate suggestions. iow: speak now or forever hold your peace :)

</with-thinking-out-loud>

this will probably be the first thing i do post 0.3, i need to get to
some mile-stone and release if i don't want to end up in an eternal
state of flux.

-- 
-Marco
Ring the bells that still can ring.
Forget your perfect offering.
There is a crack in everything.
That's how the light gets in.
     -Leonard Cohen