cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <>
Subject Re: [Proposal] Cocoon Organization
Date Mon, 05 Aug 2002 11:45:11 GMT
Amen!  YES!


>Ok, I know, one answer to this will be, if you don't want to use blocks or
>flowmaps, you don't have to. But how does this work? Will we state: "Cocoon
>the sitemap, flowmaps and blocks. But don't worry, if this is too
>complex for you, just use only the sitemap and forget about the others, you
>need them...". Well...
Not that my opinion should count, but I prefer starting with the easiest 
solution first, which is creating a
more sophisticated build system, something that smells like the Linux 
Kernel "menuconfig" or "xconfig".

>So what can we do about it? Try to act more like a team and let's more
>to the user needs. The documentation effort is one step in this direction,
>personally I think there is a problem there, too. New documentation features
>are currently delayed until forrest is ready! So, instead of focusing on the
>real problem, a new construction area has been build up (forrest) which has
>to be
>completed beforehand! This is not very helpfull.
This is what I call Cocoon Syndrome.  Someone says "documentation" and 
10 people pipe in on all the
cool tools they'll write to do documentation but no one generates any.  

Lets talk about probable effort:

1. Creation of documentation                                             
2. Creation of forrest                                                   
3. Conversion of docmentation to work with forrest.             5%

So I dare say holding up the 65% until you complete the 30% so that you 
can save on the 5% is probably errant logic.


>Second, thinking of SoC (ok, perhaps not the right context to use this
>term) - we should try to build a minimal Cocoon or core Cocoon if you prefer
>and put everything else into additional modules (read: not blocks). By
>modules I simply mean different directories in the CVS in order to
>optionally build them. Let's remove the authentication framework from the
>core, the form handling, the input modules, the flow map, the fop serializer
>etc - simply everything which is not necessary to run Cocoon.
BUT NOT seperate CVS "Modules" I hope!  That would be a PAIN.  (speaking 
both as a user and someone
who occasionally hacks cocoon).  Not trying to be pedantic with the 
verbage but whoooo.  Having everything
in its own module would hurt!

>Third, let's identify the issues for the upcomming releases.

>Fourth, let's search for volunteers for the open issues, for bug fixing and
>for testing!

>Fifth, discuss the available patches and open RTs and make proposal
>documents out of them.

>Or putting it in other words: Let's not forget the users needs over all
>this cool new features and RTs.

>Now, I'm pretty sure, that some might now stand up and say: "Hey, Carsten,
>you know what? Cocoon is open source, so if you see a need, you can
>contribute and fix it." Well, that's the individual approach we were
>following in the last months. And does it really work? Or someone will
>say "Hey, it's alpha, what do you expect?"...
+1 - Humble suggestion:  
We do this for each major release and have the committers sign off on 
it, make sure they all contribute
to it.  

>And one final note:
>Just do a simple performance test: create a pipeline reading an xml file
>transform this in two steps with two xslt transformers and serialize it
>to html (or xml if you want). Do a stress test on the same machine
>using Cocoon 2.0, 2.0.1, 2.0.2, 2.0.3 and 2.1-dev. (I don't know
>the answer to this test, but I would bet a book on the result).
>So, whew, you see I had some time to prepare this email...and now
>the flame-war can begin...
>But summarizing this: +1 on Berins idea.
>Berin Loritsch wrote:
>>Currently Cocoon is 1.5 MB in size.  That is a huge jar.  In Cocoon
>>are the core files, the servlet compatibility files, the CLI
>>files, and hundreds of components.
>>The fact that we as a community are thriving is excellent.  However, as
>>project, Cocoon is feeling quite heavy.  Esp. since there are features
>>Cocoon that not everyone needs.  I proposed this a while back, but I am
>>going to propose it again.
>>We should split Cocoon into core development and component development
>>efforts, much like Avalon does with Framework and Excalibur.  That will
>>allow the components to be packaged in jars that serve a similar
>>Things like all the database related components should be in their own
>>mini-project.  Each mini-project has its own documentation, and its own
>>life.  It also allows each mini-project to determine whether it is ready
>>for prime-time or not.  At every release, the core cocoon does not have
>>to worry about which components it has to move into scratchpad.  Also
>>each set of components has a little focused mini-community so the docs
>>get upgraded in a focused manner.
>>I have already seen the benefits of how this works in Excalibur--now
>>we are going through systematically.
>>When I am generating a site, I don't want to have to include the portal
>>components or the DB and auth components.  Those don't need to be there
>>for the site.
>>Keep in mind that the mini-projects are all part of the cocoon umbrella,
>>and they foster functioning communities within the larger Cocoon
>>not detract from it.
>>"They that give up essential liberty to obtain a little temporary safety
>> deserve neither liberty nor safety."
>>                - Benjamin Franklin
>>To unsubscribe, e-mail:
>>For additional commands, email:
>To unsubscribe, e-mail:
>For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message