cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT][long] Cocoon 3.0: the necessary mutation
Date Sun, 04 Dec 2005 10:27:52 GMT
Bertrand Delacretaz wrote:
> I need more time to think about all this, for now here are a few 
> thoughts:
>
> Le 2 déc. 05, à 18:59, Sylvain Wallez a écrit :
>
>> ...Dynamic pipelines
> ...
>> I'd like to be able to write the following in a flowscript:
>>
>>  var pipeline = flow.newPipeline("non-caching");
>>  pipeline.setGenerator("stream");
>>  pipeline.addTransformer("xslt", "normalize.xsl");
>>  if (cocoon.matchers.xpath("/foo/bar[@id = '" +
>>          cocoon.session.attributes.bar_id + "']", pipeline)) {
>>      handleBar(pipeline);
>>  } else {
>>      wrongId();
>>  }
>
> IMHO, being able to use this stuff *outside* of Cocoon, without having 
> to learn more than that, would make a big difference. A small facade 
> with a clever class loader should make it possible to embed this 
> PipelineEngine in most any java environment, not?
>
> After all these years, the really unique thing about Cocoon is still 
> the XML-based processing pipelines. Being able to use this as a small 
> embeddable component would add a lot of value to our offering.

Yep. And not only that: it can be a strong marketing asset. If 
CocoonPipelines becomes a defacto standard for sophisticated XML 
processing, it can spread in many places and bring many users. They may 
not use the web front-end at first, but are more likely to get infected 
than if they have to buy the whole thing in a single bundle.

>> ....Tell me your thoughts. Am I completely off-track,...
>
> Again, I need more time to think about all this but I like your ideas 
> very much.
>
> Trying to play the devil's advocate, the questions that come to mind are
>
> a) Do we need this?
> If we were a company I'd ask about the return on investment: from all 
> this, what are the two most important features or components that will 
> bring us forward?

There are technical and non-technical answers:
- our "customer" base is shrinking: sure many people use it, but the 
population is aging, and not much new users are coming in
- technically, Cocoon is reaching its limits in terms of evolution. Tons 
of legacy accumulated over the years make it really hard to bring in new 
things.

> b) Are we able to execute this?
> IIUC, what you're suggesting amounts to a rewrite of large parts of 
> Cocoon.

I would even go as far as saying a full rewrite. Now this doesn't means 
starting from scratch, as we have our knowledge, and lots of interesting 
code that can be extracted and placed in a new structure.

> Problem is, it seems like very few of us are currently able to 
> regularly dedicate significant amounts of time and energy to the 
> development of new things here.

Yep. But this community is slowly dying anyway, so either we go to 
retirement with a few old-timers keeping the product alive, or we 
consider more radical changes that will rejuvenate the old-timers and 
attract young people.

> Starting a big "this-new-thing-is-going-to-be-so-good" project sounds 
> very risky to me at this time, unless there's a way to do it in small 
> steps which each bring something to our users. Or unless someone who 
> wants it is able to commit sufficient resources to it, of course...but 
> we know that there has to be a community behind such an effort.
>
>> ... or do you also want to build this great new thing?...
>
> I'd love to...but I'm not sure if I have a need for that in my current 
> and envisionable projects. And the realities of life won't allow me to 
> spend a significant part of my time on it unfortunately.
>
> In the meantime, maybe offering an embeddable version of your "dynamic 
> pipelines" thing would be a great help in getting more people to use 
> the unique things that Cocoon has to offer. But it's a much smaller 
> vision than yours ;-)

Yes, but that can be the first step: define this pipeline API and the 
minimal amount of components for it to be usable (a parser, an XSLT and 
XInclude transformer and a bunch of serializers), and build on it. Doing 
it that way can also ensure this pipeline API is kept independent from 
the surrounding front-end, be it flowscript, Spring webflow or an ESB 
engine.

Sylvain

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


Mime
View raw message