[WWdevel] Preserving state on the server (was: SetMaker is slow!)

[Sam H. <sh...@ma...>]

On Jul 28, 2006, at 1:45 PM, Michael Gage wrote:

> (As Sam has
> pointed out elsewhere there are time when the data should really be  
> associated
> with the page and not the session.)

To expand on this... There's a way to store state on the server so  
that it's associated with a request, rather than with a session. I  
think the general gist of it is like this:

So you have state objects in the database (or in memory, or  
whatever). They consist of an ID number and an arbitrary number of  
key/value pairs. The state IDs should be universally unique and  
unpredictable.

Each request to the system would include a state ID parameter. Thus,  
we'd propagate "stateID" the same way we propagate user,  
effectiveUser, and key. (In fact, those variables could just be state  
variables, and the only thing you'd really need to preserve in the  
request would be the state ID.)

Whenever a request comes in, it's checked for a stateID parameter. If  
it has one, and a corresponding state record exists in the database,  
that record is cloned, and given a new ID. Otherwise, a new state  
record is created with a new ID.

So anyway, because each request has its own state record, and each  
subsequent request gets a copy of it's parent's record, you can  
always go back to an earlier page and the state for that page will  
always be there.

For example:

Go view a problem.  (window A)
  you get the problem, in images mode (the default) with stateID=1
Change the display mode to jsMath.
  the system clones state 1 -> state 2
  and sets displayMode to jsMath in state record ID 2
  you get the same page back, only with stateID=2 and jsMath selected
Now, open a link to the next problem in a new window. (window B)
  the system clones state 2 -> state 3
  you get the next problem, with stateID=3, and jsMath selected
Change the display mode to images
  the system clones state 3 -> state 4
  and sets displayMode to jsMath in state record ID 4
  you get the same page back, only with stateID=4 and images selected
Now, go back to window A and reload
  the system clones state 2 -> state 5
  state 2 had displayMode=jsMath, so state 5 does too
  you get the next problem, with stateID=5, and jsMath selected
Then, go back to window B and reload
  the system clones state 4 -> state 6
  state 4 had displayMode=images, so state 6 does too
  you get the next problem, with stateID=6, and images selected

The problem with a scheme like this is that it hides state on the  
server. Also, old state records need to be purged at some point,  
which makes old URLs lose whatever state was stored there. We'd have  
to be really careful about what we used it for -- going back to an  
old link and having the display mode revert to the default doesn't  
seem so bad, but other things might not fail so gracefully.