Le 4 déc. 05, à 11:27, Sylvain Wallez a écrit :
Bertrand Delacretaz wrote:....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....
I like this as an initial vision for Cocoon 3.0: take a small part of what we have that is really unique (XML processing pipelines), and repackage it as a small POJO-based thing that people can use in different contexts.
I've thought a bit more about your RT, and I think the single most important thing in ensuring a future for Cocoon and the community is
** We need to play better with others **We have some great things (Pipelines, Forms, Flow as an innovative way of glueing java components together, Continuations) but to use them people have to commit to Cocoon as a whole. It's a big decision, and considering the amount of (justified) uncertainty about Java's future as an application language, I think less people will make this decision in the next year.
I think being able to deliver our good things in smaller embeddable packages would make a big difference: people can then pick what they need from Cocoon yet continue working with the tools that they're used to.
If the overall Cocoon offering is useful to them, they might switch completely later on, but at first they'd just use parts of Cocoon within their existing environment, and start to love them because they're useful to them, not because we told them to love these things (which is what we're trying to do currently, with little success).
As a nice side effect, such a structure would *force* clean modularity on us.
So my conclusion is: the mutation that we need is towards embeddable POJOs, which allow our unique stuff to be reused elsewhere, in small packages.
The dream of having the Java applications world switch to Cocoon is over, yet we have many cool things to offer - this is an opportunity to broaden the use of these cool things.
-Bertrand
smime.p7s
Description: S/MIME cryptographic signature
