cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: [RT] Less is More, Finite State Machines and Balkanization
Date Mon, 14 Jul 2003 10:07:20 GMT
Bertrand Delacretaz wrote:

> I agree very much with Nicola, basically "only one implementation of 
> something in the main part of the CVS tree, variants live in the 
> scratchpad until voted to be integrated or discarded". 

I agree as well :)

> In the same spirit, it might be good to ask for a vote (or at least a 
> discussion) before adding any new block to the main code, to help keep 
> things focused.

Yes I think this is important. There are currently more than 40 blocks 
and some parts of core that probably would fit better in small blocks. 
This diversity is of course very impressing and makes the samples 
section of the demo webapp quite cool. But are there community support 
for all these blocks and components?

As it is now, a new user of Cocoon must first evaluate if Cocoon as a 
whole is suitable and stable enough for the users needs, then the new 
new user must evaluate the blocks that he or she finds interesting as 
well. This evaluation can be done from a technical POV by reading the 
documentation and browsing the code and from comunity support POV by 
checking for diversity in the CVS-logs and for discussions in the mail 
lists. Such an evaluation is booth demanding and time consuming.

IMHO we should make clear which blocks that actually has community 
support by having a vote about each block. One possibility would be to 
differ between three categories of blocks:
* Supported blocks - blocks with community support
* Contributed blocks - blocks that are stable but does not have diverse 
enough community or are percieved to be outside the Cocoon communities 
focus area
* Scratchpad blocks - development of new ideas

The requirements for supported blocks should IMHO be thought of like a 
downscaled version of the Apaches rules for project inclusion i.e. 
requirements on a healthy community.

The contributed blocks could reside in a seperate CVS module and 
documented in a separate section of the website. Maybe they should even 
be (possibly incubating) sub projects of Cocoon.

                                        -- oOo --

Will not all those problems be solved when we introduce the "real 
blocks". With all respect for the elegant and inovative design of the 
"real blocks" I believe that the greatest challenge is not techical but 
has to do with the community process of deciding what Cocoon should be 
and what the focus should be. When we know that, techology will 
certainly help.

IMO we don't have to or should wait for real blocks for starting to 
decide what is supported block and what is not. It is completely 
possible today to have external blocks, as I tried to describe in 
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105795597416396&w=2.
To install an external block one need to copy the block to the blocks 
section in cocoon, edit gump.xml and jars.xml and recompile. Not that 
complicated, installing an emacs packages has about the same complexity 
level. I would also assume (although I lack the knowledge in Gump and 
the Cocoons build system to be certain) that it could be made as simple 
as adding a jar file to the blocks section and recompile.

/Daniel



Mime
View raw message