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/[EMAIL PROTECTED] = '" +
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
