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
