[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