[Seaside] Some questions about Seaside architecture
Oleg Mürk
oleg.myrk at gmail.com
Mon Dec 12 23:58:19 CET 2005
Hi,
Thanks for fast response :)
On 12/12/05, Lukas Renggli <renggli at gmail.com> wrote:
>
> > * If instead of "blocking calls", one would have primitive:
> > callAsync(component, onCompleteEventHandler)
> > how much the design of Seaside framework would change?
> > Would it still use continuations? Or would it suffice
> > to have event handlers (that never block) implemented
> > using closures?
>
> I am not sure what you mean, but I think this is what #show:onAnswer:
> (as shown above) already does.
OK, I'll try to ask a more straightforward question:
Imagine we have a component based framework in Java, which has only event
handlers and does not have call operation or any other form of blocking for
events
(think Swing or any MVC).
I have a very simple idea how to add Seaside-style call functionality to
it:
1) Create a "CallStackComponent" that maintains a stack of components and
allows to be active only the top-level one. The interface for calling
components would be:
callComponent(
new Component(),
new CallCompleteEventListener() {
onComplete() { ... }
}
)
(we have experience with implementing such construction)
2) If one has access to partial continuations, one could very easily
transform
all event handlers of the form
component.addEventHandler(new EventHandler() { onEvent() { ... } }
to the form
event = component.getEvent()
event.await()
,,,
Essentially "event.await()" would work as follows:
await() {
call/cc cont ->
component.AddEventHandler(new EventHandler() { onEvent() {
cont }})
escapeFromEventHandler
}
3) Note that continuations are needed only for simulating blocking event
handlers.
All the rest can be written using for instance Java features.
Am I missing something? :)
> * Is it possible to "block" for some events other than "answer".
> > Would it be possible to write something like:
> >
> > buttonYes = new Button()
> > buttonNo = new Button()
> >
> > eventYes = buttonYes.getOnClickEvent()
> > eventNo = buttonNo.getOnClickEvent()
> >
> > event = eventOr (eventYes, eventNo)
> >
> > waitEvent(event)
> >
> > if (eventYes.hasOccured)
> > message "You pressed Yes!"
> > else
> > message "You pressed No!"
>
> Of course you can do this when 'rendering' the buttons (or anchors,
> whatever) ...
>
> html submitButton
> callback: [ self inform: 'You pressed Yes!' ];
> text: 'Yes'.
>
> html anchor
> callback: [ self inform: 'You pressed No!' ];
> text: 'No'.
>
> ... however an approach using a separate component that answers ...
>
> (self confirm: 'Yes or no?')
> ifTrue: [ self inform: 'You pressed Yes!' ]
> ifFalse: [ self inform: 'You pressed No!' ].
>
> ... gives better reusability of the code.
I was thinking of a more general case:
* Having subcomponetns with events e1, ..., eN
* Write a linear program, which can
* Wait for OR (or AND) of these events
* And then cotinue (see my example above)
I hope I made myself more clear now :)
> * 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).
> > * Is 'registerObjectForBacktracking' essentially equivalent of Java
> > serialization with exception that some objects are omitted?
> > Does it make a shallow or deep copy of registered objects?
> > Does it give substantially better memory footprint in useful
> > configurations?
> > ... as compared to copying whole application tree on each
> request.
>
> You are able to copy whatever you want by overriding #snapshotCopy,
> that defaults to #shallowCopy. Copying the whole application-state
> doesn't make sense, it is a design decision that has to be made during
> the development, see
> http://www.lukas-renggli.ch/seaside/advanced/slides/Backtracking.pdf.
ok, I'll read it.
> * How does 'registerObjectForBacktracking' work with garbage
> > collection?
> > Weak refereces?
>
> Yes, the default-implementation uses weak-references. At lest
> everything will be collected at the session-timeout.
nice :)
> * 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?
> * 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.
> * Would it be feasible to implement copy-on-change saving of
> snapshots
> > for backtracking?
>
> Yes.
Any reference, please? :)
> * What is Your opinion, whether it would be feasible to implement Java
> > version of Seaside using:
> > http://jakarta.apache.org/commons/sandbox/javaflow/
> > (note that this is weaker than real continuations & call/cc) and not
> > using
> > Java threads to imitate continuations like LakeShore does:
> > http://lakeshore.sourceforge.net/usersguide.shtml
> > Or is there some other important language feature missing?
>
> Yes, this is certainly possible, however I wonder if it will ever
> reach the the elegance of Smalltalk?
Well, at least it would be more elegant than many other popular Java
solutions.
Java has an exteremely large market & mind share...
Moreover, JavaFlow is not Java right? As far as I understood it is a
> JavaScript dialect running
> within Java? So why not building a Smalltalk VM inside Java and run
> Seaside code within Java? ;-)
Actually, it is pure Java. There is a bit too little documentation, but may
be this one is better:
http://rifers.org/wiki/display/RIFECNT/Home
I haven't tested these, but is seems that some smart people invented some
way to have
a limited form of continuation (suspend/resume) needed for this particular
task.
> > * Can one backtrack mutable variables within the closures that
> > are not referenced from components?
>
> Yes.
>
> This is in fact already in Seaside (I never used this feature so far),
> override #isIdenticalToSnapshot: to control if a object has changed in
> respect to backtracking.
I guess You meant my other question - about copy-on-write?
Thanks, for Your time,
OM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://liststest.squeakfoundation.org/pipermail/seaside/attachments/20051212/6bde89ad/attachment.html
More information about the Seaside
mailing list