[Seaside] Seaside Thoughts & Questions

[Daniel Drasin]

Subject: Re: Seaside - love it!
       Date: Sat, 26 Apr 2003 18:26:28 -0400
      From: Daniel Drasin <dan at drasin.org>
        To: Avi Bryant <avi at beta4.com>
        CC: julian at beta4.com
 References:1




Avi,

Thanks for the reply.  From your response it sounds like you've thought
a lot about these items, so i'll dump some more thoughts and see how
they mix.  Note, that i'm only somewhat familiar with the underlying
mechanics of seaside, so forgive me parading my ignorance...

(see below)


Avi Bryant wrote:
> 
> On Sat, 26 Apr 2003, Daniel Drasin wrote:
> 
> > Avi & Julian,
> >
> > Been using seaside for a month or so and love it - wanted to let you
> > know.  (Writing a game engine and wanted to quickly put a web front end
> > on it.  It was quick and easy - a very nice change from request/response
> > hell).
> 
> Great to hear.  What kind of a game?

The game is called "Lost Worlds."  It's an old (15 years?) character 
combat game that has a neat mechanics system that works without dice.
I thought it would be fun to build the mechanics engine in OO
(the rules are easy for a person to understand, but hard to program
without a rich underlying model - good match for OO).  At any rate,
i got through phase 1 and am starting to put some finishing touches
on it to make it look decent.  Then i'll add some user login, saving
capabilities, and AI (right now the computer player is stupid).  
At some point i need to figure out if i can put this out for people 
to play without getting in copywrite trouble, etc...

Here's a little info on it.

http://www.flyingbuffalo.com/lostw.htm
 
> > At any rate, having mulled it over i had a couple of thoughts/questions and
thought you guys might know that answers.
> 
> > - anyone done any work on porting seaside (or something like it) to
> > java?
> 
> There would be a number of obstacles.  The biggest is that there is no way
> to do continuations in Java, so the back button simply wouldn't work, and
> even without the back button you'd have to maintain one thread/session -
> which is pretty heavy weight in the Java world.  The whole HtmlRenderer
> thing would be a lot uglier in Java as well - anonymous inner classes are
> not a good substitute for blocks.
> 
> More feasible would be implementing something on top of a JVM-based
> interpreter of some more reasonable language, like the SISC scheme
> interpreter.  That would still be a lot of work, though.  What would be
> the advantages from your point of view?

Let me say at the outset that i tried something like this a couple years
ago when i was on contract at FirstUSA and was working on building
a presentation server - something that would allow application
developers
to build their apps once and then have UI developers create the 
front-ends for the different platforms hooking up to the same
application.  Only got to the prototype stage before other priorities
came up (you can imagine.)

i'm not sure i understand the comment on continuations.  Do you 
mean that they key is to be able to "rerun" a button press from a given
page (after going "back") to it?  [I'm guessing this is where the value
of continuations comes in over just using threads to store the stack - 
threads being transient and going away after they are resumed].  Is that
it?  Or is there something more to it.

Assuming that's true, i would think it would be a reasonable restriction
to "disable" the backbutton by expiring the pages.  (This was the 
approach i took - actually had a dispatching servlet which made sure
the request came in the right order and if not, reset the user to the
right place - seemed like the only way to achieve part2 below to
make things work across UI paradigms...)

As for the syntax in java question, there are a couple of solutions
1. deal with inner classes, not so bad once you bite the bullet and 
get used to them (the mind can block noise out pretty well after a
while)
2. preparser.  This is becoming a popular java solution (xDoclet an
JAspect are good examples).  
3. java api.  Something along the lines of S-Expr could handle most
cases, i'd think.

1. is probably the way to start (easiest), but 2. is probably the 
right long term approach (which could of course be combined with
a solution to the continuation issue - since you could rewrite all
method calls...)

At any rate, the big benefit i've found in seaside is the avoidance
of request/response.  I think it would be a big hit in the java
space too.  Maybe someday... 
 
> > - anyone thought about decoupling the application response from the UI
> > building?  (e.g. adding an extra layer of indirection [command pattern]
> > to encapsulate all UI interactions - see example below.).  This would
> > allow users to swap out different front ends (HTML, VB, Java, etc.).
> > This becomes really powerfull now that the "request/response" paradigm
> > is converted into the standard control flow of client-server
> > applications - now you can front end a single set of application logic
> > (not just business logic) with all the different client interfaces types
> > (without needed extra logic on the client).
> 
> I've certainly thought about this - whether or not seamlessly swapping UIs
> out is feasible, it definitely seems like Seaside's approach could be
> usefully applied to a thin client paradigm.  But thin client systems do
> not have a very good success rate right now - web apps, for all their
> clunkiness, have some huge advantages.  So while the possibilities
> interest me, I'd have to have a pretty compelling reason (like a request
> from a client) to do much work in that direction.

True, true, and true.  However, thin clients will have their day still 
(IMO).  Their the only reasonable solution for business and enterprise
applications of any significant complexity.  And 
once thin-clients are in place, it'll be only logical to 
want to swap them, which will lead to demand for 
common communication styles (which unfortunately will probably mean
that all of these apps will go to the lowest common denominator - 
request/response...)  At any rate, there is a signifacant amount of
stuff going on in the thing client space - MSFT has some stuff in .NET,
Macromedia is coming out with some stuff (part of their flash stuff),
there are some independents too, plus probably a lot i dont' know about
- i used to work in that space, but no longer...

> I don't understand the benefit in your example below, however, of
> separating out the "bindings".  Method names are already a level of
> indirection - why refer to 'PlusButton' rather than #increment?

Sorry, the example was pretty terse.  The key was that the UI 
components are assembled in one place and bound to application 
flow in another area.  That allows the application flow to be
defined the same across all of the UIs regardless of the medium.
(This is a gross simplification since some parts of the UI assembly
will have to change significantly across different mediums, but 
hopefully you get the idea...)

As for your comment on method names being an indirection, that
is absolutely correct.  However, in seaside those blocks can
contain arbitrary code and they are in a context to directly
refer to elements of the UI (rather than indirectly through
a mapping layer).  (That's the difference between refering to
the element with a tag and calling the method directly from
the block - getting rid of the context).

This indirection is key if you consider the distinction between
application intention and implementation.  Take the example of
a form, that you want to tell the user that they forgot to
enter some information.  You'd want to tell the UI element
(some sort of text element) to highlight itself.

        (UI elementNamed: #textfield) highlight.

In HTML, this would probably mean put a red *, next to it, in a
windows application, you'd have the widget flash.  Of course,
this abstraction could be implemented in a lot of ways - add the
"common" api to all UI elements, create wrappers, etc.  But the
key is the separation of application intention from UI implemenation 
(which is what i was getting at).

> >  -anyone done any work to implement a server monitor for seaside (keeps
> > track of users, their requests, etc. and presents them to through an
> > admin UI)?  I couldn't find any out there so i wrote a quick and dirty
> > one, but would love something better.
> 
> None that I've seen (if you want to send your work in I'd love to take a
> look).  This is definitely something we'll want to build in earnest,
> eventually...
> 

Be happy to - i'll clean it up a bit first ;-)  I'm not really happy
about how i had to hook into the system to get the information, so an
suggestions are welcome.  Also, i just threw some ideas into it in terms
of how to capture information, how long to hold on to it, etc. So again,
feedback always good.

Thanks for taking the time.

Dan