You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stefano Mazzocchi <st...@apache.org> on 2003/07/14 19:54:43 UTC

block management [was Re: [RT] Less is More, Finite State Machines and Balkanization]

On Monday, Jul 14, 2003, at 05:07 America/Guayaquil, Daniel Fagerstrom 
wrote:

> Bertrand Delacretaz wrote:
>
>> 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.

[skip comments I completely agree with]

>
> Will not all those problems be solved when we introduce the "real 
> blocks".

No. I actually think they will be even worse. A order of magnitude 
worse. In fact, if having different flow implementations in the core 
might remove focus and fragment the community, real blocks will take 
that danger to new and previously unknown regions.

>  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.

I can hardly agree more.

> 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.

The current build system is not designed with that ease-of-deployment 
in mind, exactly because "real blocks" will make that unnecessary (and, 
hopefully, will also make unnecesary the use of the "real" adjective in 
front ;-)

But nobody stops from making it so (a further step to the block 
modularity concept).

BTW, I've been thinking about this a lot in the last few weeks (that's 
why the flow abstraction proposal triggered 'balkanization' thoughts) 
and I think I have an few architectural solutions (expecially on the 
design of the block librarians) that might help us controlling the 
block explosion.

More on this when we start implementing the real blocks.

As for now, I think we should just release and see what happens. That 
feedback will help us know what to do in the future.

--
Stefano.