[Seaside] Seaside Internals
Stephen Pair
stephen at pairhome.net
Tue Sep 9 00:31:48 CEST 2003
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
More information about the Seaside
mailing list