On Wednesday, Oct 8, 2003, at 19:22 Europe/Rome, Ryan Hoegg wrote:
Hi,
I've been following the block design discussion and wiki evolution with great interest for a couple months now (blame Geoff). Blocks look wonderful, and I can't wait to develop my cocoon based applications as blocks.
I have a concern about the bundling of exposed avalon services with blocks. Specifically, in the recent thread about "Finishing the First Phase of Block Design" and on http://wiki.cocoondev.org/Wiki.jsp?page=BlocksDefinition I see some duplicated effort. As Stephen McConnell noticed, some of this functionality is already built, tested, and maintained in several avalon containers. Why not package avalon blocks/services/components in the way the container expects, and include them somewhere like /COB-INF/lib or /COB-INF/public/lib? Or, even cleaner separation can be had in some cases by deploying them to the avalon container independently.
If things are done this way, the problem noted in the thread I mentioned above could be completely avoided. There would be no need to expose classes through the block interface because all java would be exposed as avalon services.
I think this would simplify the block design greatly, and allow us to focus on cocoon-specific aspects.
Let me see if I get this right: you are proposing that we make cocoon blocks
somewhat extend avalon blocks and we have /block-inf/ for information on the java components and /cob-inf/ for all the remainding cocoon-specific things, in order to be able to reuse existing avalon code?
But how can I describe dependencies if one part uses implicit ones and the rest uses explicit ones?
-- Stefano.
