[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