[Seaside] Some questions about Seaside architecture
renggli at gmail.com
Tue Dec 13 07:36:56 CET 2005
> > > * Back-button suport:
> > > * Are continuations essential to back-button support?
> > Yes, it is essential being able to take a snapshot of the
> > execution-context if you have a flow of components. Simple
> > applications that just #call: and #answer: without defining a flow
> > (multiple conditional/looped calls) might just work using only #show:
> > and #answer:.
> Could You elaborate, please. May be some informative example.
> For instance, what is missing in the scheme proposed above
> (that does not use continuations that heavily).
> I want to stress, that I am talking about CONTINUATIONS not CLOSURES
> (which are analogues of event-handlers in Java).
I guess it is not essential, it is possible to tranform any piece of
code using continuations into one using continuation passing style
(event handler passing style), however if you have more complicated
flows this starts to be very messy and unnatural soon (as seen in the
simple example below):
[ self call: a ] whileTrue: [ self call: b; call: c ].
self call: a then: [ :answer |
answer ifTrue: [
self call: b then: [
self call: c then: [
self cps ] ].
How would you write this with event-handlers? Will anybody understand the code?
> > > * Can one backtrack mutable variables within the closures that
> > > are not referenced from components?
> > Yes.
> Could You elaborate, please, how it works? Do I still have to
> registerObjectForBacktracking every mutable variable i create?
Yes, if you want the variable to be backtracked. Experience shows that
there are only a few variables that need to be backtracked, again see
> > > * Are Seaside sessions serializable? Are closures serializable in
> > > Smalltalk?
> > No. And it is certainly not easy to do, because a closure might
> > reference the whole image; however if somebody is willing to invest
> > time and/or money this could be possible. In Smalltalk one can do
> > everything ;-)
> I think serialization is quite crucial for fail-over clustering and
> long-term sessions, isn't it? For instance, Java Servlet API allows
> session serialization.
I agree that this would be nice. As Avi mentioned, the easiest thing
to do right now is to save the whole object memory.
> > > * Would it be feasible to implement copy-on-change saving of
> > > for backtracking?
> > Yes.
> Any reference, please? :)
The source-code is the only reference I can give you right now.
More information about the Seaside