[Seaside] Some questions about Seaside architecture

Oleg Mürk oleg.myrk at gmail.com
Tue Dec 13 18:14:32 CET 2005

Guys :D

I really appreciate Your opinion about the back-button, but I'd
rather not dive into this discussion further, at least not on this
thread (it has a potential to become a very long thread :))))
My experience shows, that back button can create REALLY
heated discussions :D

I have asked some quite technical questions (ok, some are evaluative)
and I would really appreciate if someone could answer them (see below).
I am not arguing, just asking for Your experience/knowledge.
Actually, most of the questions were already answered by Lukas & Avi.
Many thanks!


---------- Forwarded message ----------
From: Oleg Mürk <oleg.myrk at gmail.com>
Date: Dec 13, 2005 1:31 PM
Subject: Re: [Seaside] Some questions about Seaside architecture
To: "The Squeak Enterprise Aubergines Server - general discussion." <
seaside at lists.squeakfoundation.org>


I would like to thank everyone for Your answers :)
Below are my conclusions from this discussion and some more discussion

* Continuations are syntactical sugar for the end-programmer (using
  The framework could be easily implemented with only event-handlers, using
  if needed.

* Back-button support could be implemented also in any event-based without
  continuations. This point is important, IMO, becase proper back-button
  is often attributed as being possible only with continuation-based

* It easy to add blocking semantics of waiting for events to any event-based
  MVC system (think Swing, etc) if the language supports (partial)
  continuations (Java included). So that one could write instead of:
        new Component(),
        new OnCompleteEventHandler() {
            void onComplete() {
                    new OnClickEventListener() {
                        onClick() {
                            // process click
  something like:
    callComponent(new Component())
    event = button.getOnClickEvent()

* Blocking for events
    Seaside currently does not support blocking for any other event than
    although it is theoretically feasible.

* Sessions
    Sessions are not serializable in Seaside/Smalltalk, but in theory it is

Now some more discussion points.

Back-button support
* Do You think it is possible to enforce proper back-button support rules
   in say 10-developers 2-years project?
* How easy it is to make mistakes and how easy it is to debug & find them?
* Wouldn't mistakes with back-button support be dangerous for application
* My personal opinion is that on a larger project it makes sense to forbid
   using back-button, because it is infeasible to ensure that everyone uses
   this functionality correctly, and potentially this creates security

Serialization of sessions
* Although I agree that in many use-cases serialization of sessions is not
   and one could get along with sticky sessions for load-balancing.
* There are applications (eg important internal apps with many users) that
   both long-lasting sessions and some level of reliability (server

Java vs JRuby vs Smalltalk
* Avi asked why I limit myself with Java and why not choose some other
* Although I have been in position when I had to choose platform,
frameworks, etc.
* I am currently in position of master student thinking of framework design
principles :)
* What regards Java, then I think it is not going away anytime soon. There
   vast investment in tools & developer skills.
* At the same time, I think, most of Java Web technology (Servlet API, JSF,
   most web frameworks) has rather limiting & convoluted design.
* So there is large space for improvement in Java world.
* I am not that well informed of .NET, but my impression was that
   quite convenient at page level, provides little support for complex
control flow
   between pages.

Some more comments:

On 12/12/05, Avi Bryant <avi.bryant at gmail.com > wrote:
> >     * 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.
> I'm not even sure what "the whole application tree" would mean: you
> have to draw the line somewhere, unless you want to fork the entire
> process every time (which is almost certainly not what you want).

One option (often practiced) is not to keep references to domain model
between HTTP requests. In this case each session is quite isolated
and does not reference half of the application.

>     * Can one backtrack mutable variables within the closures that
> >       are not referenced from components?
> The standard approach is to use a "StateHolder" object - a
> backtracked box - for mutable variables.

OK, although it seems rather easy to forget  to use it from time-to-time.

>     * Are Seaside sessions serializable? Are closures serializable
> > in Smalltalk?
> Yes, provided you serialize enough context with them.  The simplest
> (and often most useful) example is to simply persist the entire
> object memory of the running process by doing an image snapshot.

I would definitely want to serialize each session separately.

> * 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?
> Can you say a bit more about how javaflow is weaker?

I haven't investigated in detail, but my impression was that it provides two
* suspend & escape
* resume
which is enough for getting rid of event handlers, but does not allow to do

> As for the broader question: from my point of view Java's biggest
> limitation here is its syntax for event handlers (anon inner
> classes).  It's simply too verbose to be practical to use it as
> extensively as Seaside does blocks...

It's not that bad, although far from perfect :)

if you're tied to the JVM (why?), then something like JRuby would seem a
> much better bet.

[ I really don't want to start religous war :) ]

I have to admit I haven't made up my mind on dynamic vs static typed
and I don't know enough Smalltalk/Ruby to have an informed opinion. But,
right now
I think that a dynamicly typed language with possibility to annotate types
(+ closures & continuations) AND with mature tool support would be the
best option.

But its a completely different topic :)

Thank You for Your time,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://liststest.squeakfoundation.org/pipermail/seaside/attachments/20051213/661c4074/attachment.htm

More information about the Seaside mailing list