Daniel Fagerstrom wrote:
> 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.
>
sure, but more importantly: anyone could!
if you ask me, it's time to cut up the cake and give everyone a piece.
and I surely don't think this is going to divide the community, yeah
maybe there are going to be less people using the full stack as we know
it, but I'ld bet ya there is to be more people that could sit in on the
next gettogether :-)
seriously, I would love if e.g. our sax filtering expertise, and surely
our great concept of the source-resolver could be influencing far more
projects out there (think fop, batik,...) if we can build a bottom stack
that is usefull for all, all (will, well at least) could be building
components that are usefull for cocoon ('s higher layers)
if nothing else, it would probably make it easier to write unit
tests/docs for the lower layers...
regards,
-marc=
> /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=
>
>
--
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]
