Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <4392C985.7040402@apache.org>
Date: Sun, 04 Dec 2005 11:48:37 +0100
From: Sylvain Wallez <sylvain@apache.org>
User-Agent: Thunderbird 1.5 (Macintosh/20051025)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT][long] Cocoon 3.0: the necessary mutation
References: <43908B84.7070909@apache.org>
 <7557e99f0512030811r3e697723uf741b6504418e747@mail.gmail.com>
In-Reply-To: <7557e99f0512030811r3e697723uf741b6504418e747@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Gianugo Rabellino wrote:
> On 12/2/05, Sylvain Wallez <sylvain@apache.org> wrote:
>
>   
>> All this to say that if we want Cocoon to have a bright future, it must
>> go through a mutation. This RT dumps my current ideas about this,
>> depicting something that IMO better fits today's needs while taking into
>> account many years of innovation and what we learned from them.
>>
>>     
>
> Thanks *so* much for this, Sylvain. Your words echo what I've been
> thinking from a long time: Cocoon is a great framework with lots of
> unexpressed potential, and I definitely think that in this stage of
> our lives, we need a revolution much more than an evolution. All the
> latest and greatest in Cocoon development lately have been little more
> than finding solutions to our own problems, instead than questioning
> ourselves with the idea of changing perspectives and seeing the real
> problems. A perfect example, to me, is the whole block scenario: over
> the last few months I came to realize that if we need such a
> sophisticated beast to manage our complexity, this means that we are
> just too complex, period.
>
> So, back to the revolution scenario, I'd love to throw my pebbles in
> the lake and see if they can be of any use: first of all, I don't
> really believe that the situation to our problems can happen via
> evolution (say 2.x stuff): if you look at what people is expecting
> today, you'll notice how things might be best accomplished by a clean
> slate approach, which takes issues such as backward compatibility with
> a grain of salt, being ready to deal with it, swallow the idea of
> either sticking to 2.x (which will still be around for a long time) or
> rewrite good portions of what you've got and be done with it. If we
> are to revolutionize, well, this is a good time to have a look at the
> war we have been fighting and the battles we won and lost, in order to
> learn from our mistakes.
>
> Starting from our mistakes, today I tend to say that one of the areas
> where we have completely failed is the idea of not-so-technical people
> managing the applications: we had been figuring out, in our little SOC
> world, that people would have written bits of functionality, with
> management tying them into sitemaps. The equation
> non-technical-people=XML files would have worked like a charm, but
> what's actually happening is that sitemaps are strongly in the
> developer's domain, and developers aren't that comfortable with angle
> brackets and bloated syntaxes. The next incarnation of the sitemap,
> whatever that's going to be, must be as developer-friendly as
> possible, which means concise and effective, something we don't really
> have today.
>   

That's where dynamic pipelines, i.e. a programmatic access to pipelines, 
can be of great help.

> The second point I hate most in today's Cocoon is the TIMTOWDI effect.
> Cocoon applications, written with no discipline, unfortunately can be
> as messy as Perl or even worse: everytime I'm faced with a new
> Cocoon-based app I tend to have a way too hard time understanding what
> the flow is like and which components are used in what order:
> component declaration, private pipeliens, actions, mounts and the
> cocoon:/ protocol tend to get too much in the way of a developer, and
> I'd love to see it changed. True, there is no need to look any further
> than the sitemap to see what happens (well, flow changed the picture
> quite a bit there), but is the sitemap is a tangled mess, this is of
> little help.
>   

Actually, with the pipeline API, the ability to expand aggregations 
inline and virtual pipeline components, I'm wondering if we still need 
the "cocoon:" protocol at all.

<snip/>

> +1 for a POJO based Cocoon, not sure about container replaceability
> (tends to be an Holy Grail nowadays).
>   

Right. Let's keep the POJO thing and provide integration with a single 
container, but still allowing people to use another one if they have the 
need to. Practically, that means avoiding at all costs dependencies of 
the code on the container. Pure POJOs may not always be practical 
(thinking mainly here about component selectors), and in that case we 
must define our own lightweight abstractions that fit our needs and 
bridge to the actual container.

>> My impression is that with all these changes, Cocoon will be sexy again.
>>     
>
> A few words about the "sexy" stuff which has been perceived
> differently in the responses so far: we need sexy stuff if we want to
> have an healthy, diverse and growing community. Sexyness and adoption
> generally go hand in hand.
>   

Yup.

>> Add a bit of runtime analysis of databases and automatic generation of
>> CForms to the picture, and you have something that has the same
>> productivity as RoR, but in a J2EE environment. It also includes what I
>> learned when working on Ajax and the consequences it has on the overall
>> system architecture.
>>     
>
> Don't forget tools! In Cocoon 2.x it's basically impossible to provide
> decent productivity tools because there are too many components with
> contracts being too loose. If Cocoon 3 has to happen, this is one of
> the points I will tend to commit myself to, ensuring that every
> functionality can be easily managed, deployed and monitored (JMX,
> anyone?) and that those mundane and boring tasks that affect a Cocoon
> developer's life can be done using some fancy web interface or an IDE.
>   

JDK 1.5 has a JMX console and AFAIU Spring allows to easily JMX-ify 
beans. So that may come for free.

>> Tell me your thoughts. Am I completely off-track, or do you also want to
>> build this great new thing?
>>     
>
> I'm with you with all my CFT

CFT ???

> Hope to talk about all this with some fellow Cocooners next week in San Diego.
>   

Yep. An intersting discussion subject :-)

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://bluxte.net                     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director