[Seaside] About Seaside 3.0
stephane ducasse
stephane.ducasse at free.fr
Sun Jul 13 19:35:10 UTC 2008
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
>
More information about the seaside
mailing list