Great analysis Marc (and Bertrand)! Getting our core stuff layered and
reusable should be our main focus. After that we can build all kind of
great new inovations above it if we feel like it.
/Daniel
Marc Portier wrote:
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=
