[Seaside] About Seaside 3.0

[Norbert Hartl]

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