About Seaside 3.0

> Stephane - I agree with your two points.  Note that Gemstone and  
> Cincom seem to agree on the persistence issue (but are taking  
> radically different approaches to addressing in).
>
> I'd like to see some discussion about making it easy to deploy  
> Seaside on the Amazon cloud.  Make it easy to build sexy apps  
> (better components), easy to use and scalable persistence (AWS) and  
> we have a really great story.  The Cog VM would be icing on the cake  
> (it would reduce the $ to deploy).
>
> -david
>
> On Sat, Jul 12, 2008 at 11:10 AM, stephane ducasse <[hidden email]
> > wrote:
> Hello guys
>
> I was driving under the rain during 4 hours and my brain was  
> wandering...
> I got to think on what would be the most important point for Seaside  
> 3.0
> Here is my thoughts: may be I'm totally wrong but I watched some of  
> the Ror stuff and
> we have to learn from them.
>
>        - Better and more ready to use components.
>        - Straightforward and dead simple to use for dummies like me  
> persistency.
>
> I think that as a community we should pay attention that this is not  
> because
> we will be technical superior we will survive (even if 2.8 and 2.9  
> cleans are cool - lukas
> and philippe know that I think that they did an EXCELLENT job).
>
> Now I'm thinking for the next step that could really blow away the  
> rest of people
> not thinking that Seaside is coooool.
>
> Stef
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>
>>
>> I was driving under the rain during 4 hours and my brain was  
>> wandering...
>> I got to think on what would be the most important point for  
>> Seaside 3.0
>> Here is my thoughts: may be I'm totally wrong but I watched some of  
>> the Ror
>> stuff and
>> we have to learn from them.
>>
>>       - Better and more ready to use components.
>
> Should not be part of Seaside, should be separate project.
>
>>       - Straightforward and dead simple to use for dummies like me
>> persistency.
>
> Should be separate project as well.

>>>       - Better and more ready to use components.
>>
>> Should not be part of Seaside, should be separate project.
>
> +1, there's no such thing as a ready to use UI component, one size  
> does not
> fit all and UI components don't belong in Seaside.  I'd even like to  
> see
> #request: and #inform: removed because it plants such ideas in peoples
> heads.  Seaside can be used to build many UI frameworks, like wrapping
> MooTools, YUI, XUL, or the myriad of other current and future UI  
> components.
> There's no reason you shouldn't have a choice between any of the  
> various
> competing component libraries which should all be separate projects.

>>
>>
>> Cheers
>> Philippe
>
> Also +1, persistence is not a web framework's job, it's a persistence
> framework's job and you should be able to use any one of the various
> competing persistence frameworks with Seaside.  Ruby on Rails is not
> technically a web framework, it's a collection of frameworks in an
> application stack; that it's called a framework is more marketing than
> truth.  The web framework within Rails is called ActionPack, that's  
> what
> Seaside is.  ActiveRecord is the persistence framework used by the  
> Rails
> stack, for Seaside that's Gemstone, Glorp, GOODS, Magma, OmniBase,  
> Roe or
> the Image itself depending on what you need.
>
> If there's anything to learn from Rails, it's that the stack can  
> benefit
> from being very well integrated from an outside point of view so  
> that it
> appears all the parts were made to fit together.  That doesn't mean  
> we need
> to dump everything into Seaside, and it's too late for that anyway.  
> Rails
> came out of the gate with just ActiveRecord and everyone uses it,  
> but you
> won't get the Seaside community to do that, we already have more  
> than one
> persistence option and you aren't going to be able to pick any one  
> bless it
> as *the* one.

>
>
> There may be things Seaside can learn from Rails, but it shouldn't  
> copy
> Rails.  Convention over configuration, tight integration, simple to  
> use,
> easy to setup, all good things; on the other hand html templates, url
> hacking with regex and manual marshaling of state, integrated code
> generators/scaffolding, focus on statelessness, all IMHO, bad things  
> and a
> direction I'd hate to see Seaside go.  Even the Rails guys spent a  
> lot of
> time on 2.0 trying to push things out of the core and into plugins or
> separate gems because they realized it was a mistake including them  
> in the
> core.

> Ramon, I coulden'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
>
> On 7/12/08, Ramon Leon <[hidden email]> wrote:
>>>>       - Better and more ready to use components.
>>>
>>> Should not be part of Seaside, should be separate project.
>>
>> +1, there's no such thing as a ready to use UI component, one size  
>> does not
>> fit all and UI components don't belong in Seaside.  I'd even like  
>> to see
>> #request: and #inform: removed because it plants such ideas in  
>> peoples
>> heads.  Seaside can be used to build many UI frameworks, like  
>> wrapping
>> MooTools, YUI, XUL, or the myriad of other current and future UI  
>> components.
>> There's no reason you shouldn't have a choice between any of the  
>> various
>> competing component libraries which should all be separate projects.
>>
>>>
>>>>       - Straightforward and dead simple to use for dummies like me
>>>> persistency.
>>>
>>> Should be separate project as well.
>>>
>>> Cheers
>>> Philippe
>>
>> Also +1, persistence is not a web framework's job, it's a persistence
>> framework's job and you should be able to use any one of the various
>> competing persistence frameworks with Seaside.  Ruby on Rails is not
>> technically a web framework, it's a collection of frameworks in an
>> application stack; that it's called a framework is more marketing  
>> than
>> truth.  The web framework within Rails is called ActionPack, that's  
>> what
>> Seaside is.  ActiveRecord is the persistence framework used by the  
>> Rails
>> stack, for Seaside that's Gemstone, Glorp, GOODS, Magma, OmniBase,  
>> Roe or
>> the Image itself depending on what you need.
>>
>> If there's anything to learn from Rails, it's that the stack can  
>> benefit
>> from being very well integrated from an outside point of view so  
>> that it
>> appears all the parts were made to fit together.  That doesn't mean  
>> we need
>> to dump everything into Seaside, and it's too late for that  
>> anyway.  Rails
>> came out of the gate with just ActiveRecord and everyone uses it,  
>> but you
>> won't get the Seaside community to do that, we already have more  
>> than one
>> persistence option and you aren't going to be able to pick any one  
>> bless it
>> as *the* one.
>>
>> There may be things Seaside can learn from Rails, but it shouldn't  
>> copy
>> Rails.  Convention over configuration, tight integration, simple to  
>> use,
>> easy to setup, all good things; on the other hand html templates, url
>> hacking with regex and manual marshaling of state, integrated code
>> generators/scaffolding, focus on statelessness, all IMHO, bad  
>> things and a
>> direction I'd hate to see Seaside go.  Even the Rails guys spent a  
>> lot of
>> time on 2.0 trying to push things out of the core and into plugins or
>> separate gems because they realized it was a mistake including them  
>> in the
>> core.
>>
>> Ramon Leon
>> http://onsmalltalk.com
>>
>>
>>
>>
>> _______________________________________________
>> seaside mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>>
>> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>>>>      - Better and more ready to use components.

> Hello guys
>
> I was driving under the rain during 4 hours and my brain was  
> wandering...
> I got to think on what would be the most important point for Seaside 3.0
> Here is my thoughts: may be I'm totally wrong but I watched some of  
> the Ror stuff and
> we have to learn from them.
>
> - Better and more ready to use components.
> - Straightforward and dead simple to use for dummies like me  
> persistency.
>
> I think that as a community we should pay attention that this is not  
> because
> we will be technical superior we will survive (even if 2.8 and 2.9  
> cleans are cool - lukas
> and philippe know that I think that they did an EXCELLENT job).
>
> Now I'm thinking for the next step that could really blow away the  
> rest of people
> not thinking that Seaside is coooool.

> -----Mensaje original-----
> De: [hidden email]
> [mailto:[hidden email]] En nombre
> de Norbert Hartl
> Enviado el: Lunes, 14 de Julio de 2008 05:50
> Para: Seaside - general discussion
> Asunto: Re: [Seaside] About Seaside 3.0
>
> On Sat, 2008-07-12 at 18:10 +0200, stephane ducasse wrote:
> > Hello guys
> >
> > I was driving under the rain during 4 hours and my brain was  
> > wandering...
> > I got to think on what would be the most important point
> for Seaside 3.0
> > Here is my thoughts: may be I'm totally wrong but I watched
> some of  
> > the Ror stuff and
> > we have to learn from them.
> >
> > - Better and more ready to use components.
> > - Straightforward and dead simple to use for dummies like me  
> > persistency.
> >
> > I think that as a community we should pay attention that
> this is not  
> > because
> > we will be technical superior we will survive (even if 2.8 and 2.9  
> > cleans are cool - lukas
> > and philippe know that I think that they did an EXCELLENT job).
> >
> > Now I'm thinking for the next step that could really blow away the  
> > rest of people
> > not thinking that Seaside is coooool.
>
> Now that I read the thread as whole I have a question. What I can read
> is people having lots of enhancements in mind they want to see in
> seaside. And there are seaside developers which are trying to
> keep the
> "pollution" away from seaside :) The most enhancements would fit
> quite good in a complete web application stack. So why aren't we
> creating such a web application stack (call it "lido")?
>
> To summarize I read arguments:
>
> - things that are good ideas but that don't belong into seaside
> - help for setup of things like apache
> - useful components
> - persistency integration
>
> That sounds exactly like a thing that wraps around seaside. A thing
> that
>
> - pollutes itself with helper classes to e.g. create apache set ups
> - incorporates persistency and glue code (Glorp, Gemstone, ...)
> - that builds a bunch of useful components
> - that integrates a concept that is native to RoR people but not
>   to smalltalkers: "conventions"
>
> So, why not put the "dirt" into a stack and let the modules be clean?
> Having one-click images for the most wanted uses cases could lower the
> barrier for new users once more. And I don't think we need much more
> code because everything is there already. Building a stack would focus
> a lot more on integrating the different parts and so make it
> easier for
> newbies.
>
> Norbert
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>
>> lukas I meant 3.0 without the idea of rewriting but with the
>> idea that
>> after 2.9, 2.10 is a boring number :)
>>
>> Stef
>
> I think most people treat version numbers as major.minor, if there's  
> not big
> change then the major shouldn't be incremented, just the minor.  
> Anything
> else is just confusing.
>
> Ramon Leon
> http://onsmalltalk.com
>
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> How close is Seaside to being able to offer something like Heroku?
> http://heroku.com/
>
> This seems to be the start of the art in 'simple to get started'.  
> Start
> coding from your browser, build and deploy a 'hello world' app in 5  
> minutes,
> tell your friends to point their browsers at your site. Seems like  
> Seaside
> has most of that too, and by enabling it from the browser on a  
> hosted stack,
> all the questions about stack, integration etc disappear.

> -----Original Message-----
> From: [hidden email] [mailto:seaside-
> [hidden email]] On Behalf Of Randal L. Schwartz
> Sent: Monday, July 14, 2008 10:31 AM
> To: Sean Allen
> Cc: Seaside - general discussion
> Subject: Re: [Seaside] About Seaside 3.0
>
> >>>>> "Sean" == Sean Allen <[hidden email]> writes:
>
> Sean> What I would like to see, is the ability to take html and

> Sean> smalltalk code to generate said html from it. Then I can have a
> designer
> Sean> do their thing and take it and process it.
>
> I was thinking about that too.  Perhaps something OMeta based for easy
> extending and tweaking.  An HTMLToSeasideCode project, anyone?
>
> --
> Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777
> 0095
> <[hidden email]> <URL:http://www.stonehenge.com/merlyn/>
> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
> See http://methodsandmessages.vox.com/ for Smalltalk and Seaside
> discussion
> _______________________________________________
> seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

>>>>>> "Sean" == Sean Allen <[hidden email]> writes:
>
> Sean> What I would like to see, is the ability to take html and  
> generate
> Sean> smalltalk code to generate said html from it. Then I can have  
> a designer
> Sean> do their thing and take it and process it.
>
> I was thinking about that too.  Perhaps something OMeta based for easy
> extending and tweaking.  An HTMLToSeasideCode project, anyone?