[Pdx-pm] what's special about smalltalk

[Kevin Scaldeferri]

On Mar 15, 2007, at 9:21 AM, Randal L. Schwartz wrote:

>>>>>> "benh" == benh  <ben.hengst at gmail.com> writes:
>
> benh> I might be missing the point here but yes, jifty does emulate
> benh> continuations like seaside. As to how they go about it....  
> not a clue.
>
> One advantage seaside has over most (all?) other systems is that  
> the webserver
> is monolithic.  I can leave a closure block lying around on server  
> side with a
> unique ID, hand you that ID, and when you come back on another hit  
> with that
> ID, I can go right to *that state* again.  This is the holy grail  
> of web app
> design: to turn the "stateless" web into a "stateful" app.  Using  
> this, I can
> take a fairly straightforward "classic GUI" app and "Seaside" it in  
> just a few
> steps... what would have been a dialog box turns into a screen, etc.

How well does this work in practice?  It seems like it has similar  
issues to other session-based approaches.  For example:

How long is a continuation valid?  If I go away for a couple hours  
will I really be able to pick up again?  Presumably there has to be  
some strategy for garbage-collecting continuations or you'll run out  
of memory eventually.

How do you scale this?  Presumably you have to have a load balancer  
with "continuation-affinity"?  Or is there some way that a  
continuation can be shared across a redundant cluster of machines?

For that matter, how does Smalltalk/Seaside handle single-machine  
multi-CPU/core concurrency?

How friendly are the URLs to being passed around between  
individuals?  Partly this is an issue of expiration as mentioned  
above, but I also hope that authentication is somehow outside of the  
continuation state.


Anyway, these are pretty obvious questions, so I imagine that there  
are reasonable answers, but I'm curious to know what they are.


-kevin