catching up late on this thread, I can't help feeling Bertrand is right on the spot here, so I'm left to wonder why so little people chime in...
So include me in the camp of: we shouldn't be thinking of making the whole of cocoon even bigger or more feature-rich... not before we've seriously chopped it down in smaller chuncks that can live in their own right, and can _incrementally_ lure people into the whole... IMHO cocoon already claims territory in all directions, even if that started as convenience to the end-user and is mostly only administrative stuff this is the kind of convenience that not just hides but almost blocks access to the real meat on the bone... this should stop, and be reversed. cocoon's history rephrazed: Cocoon is a nifty XML pipeline-mechanism, hm, might get slow, no wait let me increase performance by creating some smart object pooling framework first, and now: just wait to let me show you how that works in a servlet, yeah well, no wait let me show you how to use that in a web-app with a ready web.xml to cater for encodings and stuff, no wait never mind your servlet container just do cocoon.sh servlet and you're set! So what do you think? Not impressed? Uh, how could that be? Well, wait! Now that we have everything in place we have no limitations to throw in more goodies to really make you dazzle,.. so over time we get continuations, form libs, javaflow, ajax, whatnot... (some of this makes me think about one of the insights I got from reading the CATB looong ago: this moment were Eric realizes his popclient doesn't need to be and MDA *AND* an MTA to be usefull... http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s07.html) Ok, so far the whining, if I'ld let myself wonder over what is the incremental path I would guess it to be something like this: 1. start off with jaxp/sax knowledge or die, provide our base of transformers/serializers as (only a minor step above) xmlfilters/contentHandlers 2. throw in the sourceresolver functionality (without the avalon as a requirement) allow it to have flexible registration of new types of sources, let all our 'XMLFilters' in on the play 3. only now throw in the sitemap as a xml-config way to describe your pipes and a way to re-enter the machinery through the cocoon:/ source 4. throw in an extension mechanism (yeah blocks) so more complex pipelines/and ready sitemaps can be reused and build upon each other -- (only) from here we go into web-container land -- 5. allow servlet integration through a mix of impedance-mismatch helpers - a standard way (not an own servlet?) to allow people - encoding stuff we've handled here and there - serializers - the context:/ sourcefactory - nifty url inspection/decision stuff (selectors, matchers...) 6. provide a servlet-controller-delegation pattern (now a real servlet, one of the front-controller type) to allow for various actual controllers, and allow those to be managed through fixed url's (actions) instance url's (apples) or conntinuation urls (flowscript/javaflow) 7. build on top a form-framework that eventually brings ajax support blast I didn't even mention the container, seriously: with some many of them out there, why not make our classes just clean, mean and DI ready and allow the use of those? anyway, if cocoon would allow to be used on ALL of these levels, (and not only starting off at 6) then it would be succesful, I would find it logical that the number of users is dropping as you go up in this stack... and it's precisely that effect we are facing now: pushing up in a monolithic way so we become useful for less and less... anyways, I'm jumping in late, and I've been only lurking from the sideline lately... I guess I just wanted to make sure somebody hears what (I think that) Bertrand is saying ;-) regards, -marc= Bertrand Delacretaz wrote: > 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 > -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
