Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gianugo@gmail.com designates
 64.233.184.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=qCXNke37cFUKfGM3ZgUDeXK/YEP7dYh/f6ESbe0VcAmbAJoLpBHGeBu0bBfwpElZ7xKKStrhBPJAovOby6V7RK4ExUd8KaRvswbkPrt44SSDJsXHurYsZKKQAe7+G/tAY0yQClRquukre+m7ZIBA8cVq1LtFMWcR4NLYrusQI24=
Message-ID: <7557e99f0512030811r3e697723uf741b6504418e747@mail.gmail.com>
Date: Sat, 3 Dec 2005 17:11:34 +0100
From: Gianugo Rabellino <gianugo@gmail.com>
To: dev@cocoon.apache.org
Subject: Re: [RT][long] Cocoon 3.0: the necessary mutation
In-Reply-To: <43908B84.7070909@apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <43908B84.7070909@apache.org>

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=3DXML 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.

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.

Now, on to some specific answers:

> Giving its real role to the controller
> --------------------------------------

<snip/>

> - the sitemap is the configuration of the overall request processing of
> the application (or a subpart of it in the case of mounts). It defines
> the configuration of that request processing, which is composed of
> components (<map:components>), controllers (<map:flow>) and views
> (<map:pipeline>). And I even think these 3 parts should really be split
> in different files, i.e. moving components to a xconf and pipeline
> definitions to e.g. "pipelines.xml".

A word of caution here: different files tend to mean different hassles
to maintain, test and deploy. What I'd like to see is us moving away
from configuration files as much as possible, providing sensible
defaults and easy way to override them. Be serious about YAGNI and
KISS: in years of Cocoon development I still have to find a real use
case where a subsitemap could use a different implementation of a
component reusing the name that was used elsewhere: having a central
component repository and nothing more could do the same job just fine
and make us forget about the whole <map:components/> nightmare. Not to
mention how easier it would be to provide a configuration tool,
something that has been overdue for ages. My proposal, then, would be
ditching the components altogether, moving their
declaration/configuration to a central location and be done with it.

> Expression languages
> --------------------
>
> Do you know how many expression languages there are in Cocoon? Java,
> JavaScript, XPath, XReporter, JEXL, etc. There's also all the
> micro-languages defined by each of the input modules: many of them use
> XPath, but not all...
>
> Also, the way to access a given data is not the same in the sitemap
> (e.g. "{request-param:foo}") and in JXTG
> ("${cocoon.request.getParameter('foo')}" or even
> "#{$cocoon/request/parameters/foo}")
>
> We should restrict the number of languages to the useful minimum, and
> ensure they can be used consistently everywhere.

Yes, please. Pretty please. Consistency is key.

> All this also means that we need a well-defined "cocoon" object defined
> identically in all contexts. Additional top-level objects can be
> available to provide context-specific data, such as "flow.sendPage()",
> "sitemap.resolve('../1')" or "template.consumer".

A consistent and well documented cocoon object? Boy, I must be dreaming...:=
-)

> Content-aware pipelines
> -----------------------

Again, BIG +1 here. I'm sorely missing the ability to operate based on
the content being feeded to Cocoon. Now, whether this should be done
using STaX is an interesting subject: I'm all for delving into it, but
SAX compatibility should be taken seriously (for one, XSLT is here to
stay, and today's implementations AFAICT are SAX based). This said, I
love the idea of solving elegantly the issue of buffering events.

> Dynamic pipelines
> -----------------
> Yes, you read it well: dynamic pipelines. This is what comes next
> naturally after content-aware pipelines: with use cases like webservices
> and ESBs, the content-based routing is not enough and we also need
> controller-driven routing.

As we like to say in Italy, you brought your dog to the church. :-)
But apart from then, $DEITY knows how many times I felt the need for a
(controlled) dynamic pipeline scenario so no problem here. However,
what you're suggesting as a possible implementation, also has an
interesting side effect which relates to what Bertrand has commented,
about being able to use Cocoon as an API for different scenario:
again, something that has been for a long time in my wishlist. OTOH, I
see some problems in giving too much flexibility away, so some care
should be taken.

> Core components
> ---------------------
>
> Moving to pull pipelines isn't the only important core change: we need
> to move away from Avalon for good. Now what container will we use? We
> don't care: Cocoon 3.0 will be written as POJOs, and will come with a
> "default" container. Will it be Spring, Hivemind, Pico? I don't know. We
> may even provide configurations for several containers, as does
> XFire[xxxxx].

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

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

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

> 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 (just look at the commit logs to see how
much have I got of that in the past few years, but hey... :-)) and,
responding to Bertrand on that topic, I'm not that concerned about
project resourcing: given a good plan, I'm sure we'll find enough
people to attain our goals.  Hope to talk about all this with some
fellow Cocooners next week in San Diego.

Ciao,
--
Gianugo Rabellino
Pro-netics s.r.l. -  http://www.pro-netics.com
Orixo, the XML business alliance: http://www.orixo.com
(blogging at http://www.rabellino.it/blog/)