[Seaside] Seaside Internals

[Stephen Pair]

Avi Bryant wrote:

>On Mon, 8 Sep 2003, Stephen Pair wrote:
>
>  
>
>>Sigh...it is a quagmire.  The best hope for really solving this problem
>>might be TeaTime.  The best continuation in Squeak is a snapshotted
>>image on disk.  All state in the image is captured, and you can restart
>>from that snapshot many times without worrying that the state one
>>another activation will corrupt other activations.  What's needed is a
>>transactional Squeak that would allow a very fast, efficient and
>>fundamental snapshot of the current state of the system.
>>    
>>
>
>No, the whole point of a system like Seaside is to
>separate out backtrackable state from non-backtrackable state.
>Snapshotting the entire system is useless, unless you are proposing that
>all non-backtrackable state be kept in an external DB.
>

Yes, that would work for non-backtrackable state, but that example was 
meant only for illustration and I think you might be missing my point.  
The example was meant to illustrate how you can easily make all state in 
the system be backtrackable without having to code anything special to 
get that capability.  An image snapshot is the perfect continuation 
(almost).  If I have two snapshots A and B, where B is a successor of A, 
then to jump from point B to A, I need only to dump B from memory, load 
A and continue.  In that scenario, I don't need to worry about 
declarative coding that identifies the state that is to be 
backtrackable...all state is backtrackable.  This of course doesn't 
account for state that shouldn't be backtrackable...you could use an 
external store for non-backtrackable state, but this example was only 
meant for illustration, not as a viable solution.

As you've already discovered, you really can't make any upfront guesses 
about what should or shouldn't be backtrackable...whatever guess you 
make will always be wrong for some scenarios.  This is probably what led 
you to the current implementation (of Continuation) that assumes only 
the slots in the context objects are backtrackable (the minimal 
backtrackable state needed to do a continuation). 

So, in the absence of something like TeaTime, we are left with having to 
make up front declarative decisions about what state should be 
backtrackable (i.e. we have to change our code that accesses state to 
accommodate backtracking).  With TeaTime (and I'm speaking more about 
David Reed's thesis on the subject and less about the current 
implementation of TeaTime), you might have the luxury having a 
continuation be able capture and recreate the entire state of the system 
at the point where the continuation is created (and do that pretty much 
instantaneously).  For non-backtrackable state, you would simply access 
that from a different transactional context.  The benefit here is that 
you don't need to code anything to be backtrackable...everything is 
backtrackable.  Whether or not state is backtrackable for a given 
continuation depends on how it was accessed, not how access to it was coded.

- Stephen