[Seaside] About Seaside 3.0
ramon.leon at allresnet.com
Sun Jul 13 00:48:53 UTC 2008
> Ramon, I couldn't agree more.
> To justify a major version jump from 2.x to 3.0 we need something
> radically better. Seaside 2.0 was a complete rewrite over Seaside
> 0.98. The manpower (and interest?) to start such an endavour seems to
> be missing currently.
With 2.9 not even out of the gate yet and 2.8 still the stable release,
maybe it's a bit premature to be discussing a 3.0. As long as the core is
lean, mean, and clean, and there's nothing just jumping out of the community
that looks like it should be harvested for the core, is there really a need
push for another version?
With all of the other Smalltalk's scrambling to support Seaside and bring
people from their communities in, and the various cross platform issues that
are likely to keep creeping up, maybe now is better a time to sit back and
develop some stability and let the community grow a bit without making every
chase Squeak trying to keep up with the latest version.
Here's a few ideas of existing things we could improve without needing a
* Things like Dale exploring reusing existing callback state so every hit
doesn't have to generate new state in the session.
* Maybe spend some time exploring real world issues like how to run a
single site that flips back and forth between secure and non secure pages
dynamically and generating the anchors correctly (I hacked up my own
versions of secureCallback: and unsecuredCallback: to do this on
ReserveTravel) because setting the server port and server protocol globally
on the application itself seems wrong, but maybe I'm missing something.
* How about some fancier methods built in for how sessions expire so a
rouge bot can't just come along and chew up all your ram till your image
dies. Avi had a nice idea a while back on a sliding expiration time based
on how many times the session was, simple but likely very effective against
stupid bots that hit you 10000 times with each hit starting a new session.
* How about some attention into how sessions are implemented with dynamic
variables that you lose access to when you fork a block and try to do
anything asynchronously. I'm not the only one that's been bitten by this.
* Is there a possibility of using ImageSegments to partition out the state
of a Seaside node so upgrades can be rolled out to load balanced farms by
having the running node save and quit and immediately start up a new version
to replace it so users only notice a momentary pause but not have their
sessions blown away? It's one thing to hot upgrade a site running in a
single image with VNC or the web interface, but if you're load balancing a
whole slew of nodes that's just not going to work. It's much easier to copy
out a new image and restart all the nodes.
* What about some resources for helping people running Seaside sites with
Apache, really good example Apache configs with load balancing and Dabble
style dynamic launching and shutting down of images to suite the demands of
the current load. Seaside deployment is not trivial and everyone stumbles
over these issues time and time again.
Anyway, just a few things to think about, but my point is there's plenty of
things to do now, without needing to think of some ground breaking idea that
would justify a new major version.
More information about the seaside