[Seaside] Seaside Internals

Avi Bryant avi at beta4.com
Mon Sep 8 15:24:19 CEST 2003


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.

> Well, I could imagine a server could work like this:
>
> [strm atEnd]
>     whileFalse:
>        [self dispatchRequest: self next]
>
> In #dispatchRequest:, you could fork first then fire the continuation as
> you suggest (which iirc is essentially what happens with Kom/Seaside
> with some additional lookup and concurrency controls).  If you don't
> fork first, then you'll essentially kill this request handling service.

> To me, this seem to be such a common scenario that you want to consider
> adding a method to the protocol of Continuation to do two additional things:
>
> a) invoke the continuation in a separate process
> b) add controls to prevent multiple concurrent invocations

Well, to me the common scenario here is forking for each incoming request
- that's what should be abstracted (and hey, KomServices does exactly
that).  Continuations have nothing to do with it.

But I think we may just have to disagree on this one.





More information about the Seaside mailing list