[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!
Peace,
OM
---------- 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>
Hello,
I would like to thank everyone for Your answers :)
Below are my conclusions from this discussion and some more discussion
points.
Conclusions:
* Continuations are syntactical sugar for the end-programmer (using
framework).
The framework could be easily implemented with only event-handlers, using
CPS,
if needed.
* Back-button support could be implemented also in any event-based without
using
continuations. This point is important, IMO, becase proper back-button
support
is often attributed as being possible only with continuation-based
frameworks.
* 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:
callComponent(
new Component(),
new OnCompleteEventHandler() {
void onComplete() {
button.addEventListener(
new OnClickEventListener() {
onClick() {
// process click
}
}
}
}
something like:
callComponent(new Component())
event = button.getOnClickEvent()
event.await()
* Blocking for events
Seaside currently does not support blocking for any other event than
answer,
although it is theoretically feasible.
* Sessions
Sessions are not serializable in Seaside/Smalltalk, but in theory it is
possible.
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
security?
* 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
holes.
Serialization of sessions
* Although I agree that in many use-cases serialization of sessions is not
needed
and one could get along with sticky sessions for load-balancing.
* There are applications (eg important internal apps with many users) that
require
both long-lasting sessions and some level of reliability (server
fail-over).
Java vs JRuby vs Smalltalk
* Avi asked why I limit myself with Java and why not choose some other
platform.
* 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
is
vast investment in tools & developer skills.
* At the same time, I think, most of Java Web technology (Servlet API, JSF,
Portlets,
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
ASP.NET<http://asp.net/>,
although
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
operations:
* suspend & escape
* resume
which is enough for getting rid of event handlers, but does not allow to do
call/cc.
> 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
languages
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,
OM
-------------- 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