[Seaside] Some questions about Seaside architecture

[Oleg Mürk]

Hello,

I have some questions about the internal implementation of Seaside.
I have read Seaside docs including the article
    http://www.iam.unibe.ch/~scg/Archive/Papers/Duca04eSeaside.pdf
but I would like to clarify some questions mostly revolving
around continuations and back-button support.

I don't have any experience with Smalltalk, so please forgive me
using Java syntax in my examples. Also, please don't suggest to RTFS
unless I ask something too stupid or complicated :)

* How essential are continuations to the design of Seaside?
    * How is "blocking component call" implemented? My interpretation
      of section 8.4 of the article would be that when child component
      is called, a continuation is taken, and essentially the follwoing
      code is executed:
        childComponent.addOnAnswerEventHandler(continuation)
        decorator.replaceMe(childComponent)
      To be more precise, the continuation should be partial,
      with respect to the start of event handler.

    * 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?

* 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!"

* Back-button suport:
    * Are continuations essential to back-button support?
      Or are they orthogonal?

    * 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.

    * How does 'registerObjectForBacktracking' work with garbage collection?
      Weak refereces?

    * Can one backtrack mutable variables within the closures that
      are not referenced from components?

    * Are Seaside sessions serializable? Are closures serializable in
Smalltalk?

    * Would it be feasible to implement copy-on-change saving of snapshots
      for backtracking?

* 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?

As a side note, I have participated in creating (an internal)
Java web framework which allows building composite hierarchies
of components with event-handling. Based on this one could
easily implement both reusable widgets (form controls, lists)
and such things as CallStackComponent, TabbedComponent,
WizardComponent, etc. I can confirm that possibility of having
CallStackComponent at an arbitrary place in component tree
allows building miraculously well-decomposed UI :) But we
didn't use continuations in any form, so essentially each
component was defined by a bunch of event handlers.

Keep up the good work,
Oleg Mürk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://liststest.squeakfoundation.org/pipermail/seaside/attachments/20051212/0a21057a/attachment.html