Please create feature requests on the Google bug tracker for your wishes.
On 7/13/08, Ramon Leon <ramon.leon at allresnet.com> wrote:
>>>> 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.
>>>> Cheers,
>> Lukas
>>> 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
> major release...
>> * 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.
>> Ramon Leon
>http://onsmalltalk.com>>>>> _______________________________________________
> seaside mailing list
>seaside at lists.squeakfoundation.org>http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside>
--
Lukas Renggli
http://www.lukas-renggli.ch