[Seaside] About Seaside 3.0

[stephane ducasse]

On Jul 13, 2008, at 2:48 AM, Ramon Leon 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.


yes. This is why may be my email was badly formulated (too much  
driving and rain)
I think that the packaging of things is important => better integration.



> 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.

I agree.

>
>
> Ramon Leon
> http://onsmalltalk.com
>
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>