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] Moving blocks out of the core
Date Tue, 15 Feb 2005 13:31:52 GMT
Reinhard Poetz wrote:

> Carsten Ziegeler wrote:
>
>> The more I think about it, I come to the conclusion that moving the 
>> blocks out of the core seems to be a good way to procede.
>> (Moving files with SVN is easy and the history etc. is preserved).
>> (Of course we should only move things for 2.2 - 2.1.x should be left 
>> untouched)
>>
>> Now one benefit of course is that our core gets smaller, but that's 
>> not really a reason to move things.
>>
>> But if we move the blocks, we *have to* think about a simple but 
>> working solution for configuration and dependencies. 
>
<snip/>

> Look at 
> http://svn.apache.org/repos/asf/cocoon/whiteboard/block-builder/, 
> which provides nearly everything you describe above. Additionally it 
> resolves dependencies between blocks which makes it possible to work 
> on a single block without taking care of other, non-related blocks.
>
> The only prerequisite is a descriptor file like block.xml that 
> consists of
>
>  - general meta information (author, license, ...)
>  - required blocks
>  - required libraries
>
> block.xml is versioned by a doctype like 
> http://apache.org/cocoon/blocks/1.0. This information isn't useful 
> right now  but will help the future Block*Deployer* to indentify if a 
> block and a Cocoon core version fit together.
>
> If nobody objects I would setup the BlockBuilder for Cocoon 2.2 and 
> for the portal block (+ all blocks it depends on) over the next 
> weekend. Afterwards we can evaluate if _we_ like it or not. 

Please go ahead, and if you and Carsten can agree about how to do it, 
its even better.

Anyone who dare to step forward and move out the blocks from the trunk 
will become my personal hero, be nominated by me for "the employe of the 
year", and maybe even get a beer at the real blocks hackaton ;)

> Until  now I've hesitated to propose using the BlockBuilder because 
> I've thought that it requires a fully useable deployment tool. But if 
> we follow Carsten's idea of a simple deployment tool (unpacking) this 
> isn't a problem any more.

JFDI!!!

                                       --- o0o ---

Sometimes I think that "real blocks"

  [...] is another instance of something that is becoming an anti-pattern:
  "stating the solution before stating the problem".

(Sorry for using citations in such an unfair way ;) )

Now, don't get me wrong. I belive that the block concept is a beautiful 
design and that we eventually will need all aspects of it. But we should 
sometimes remind ourselves about what problems we actually are trying to 
solve, identify whats most important, focus on that, and then try to 
find "the simplest thing that could possibly work".

So which problem is the most important?

IMO our huge community problem is what is most important. No, I'm 
certainly not talking about our excelent existing community, I'm talking 
about the fact that we only elected two new committers during 2004, 
compare that to around ten during 2003, and probably similar figures the 
years before that. Are our requirements on new committers to high? 
Maybe, maybe not, I think the standards have been high all the time.

I think it is our code base that is the main threshold for newcommers to 
start contributing. The core probably both will and must be a task for 
highly dedicated experts. But the threshold for creating a successfull 
block is much higher than it should be for non committers.

Think about an entusiastic non-comitter who starts to develop a new cool 
and really usefull block at e.g. Sourceforge. Will it have the chance to 
attract lots of users? I helped with "blockifying" Fins, it resulted in 
a +10 step instalation guide 
http://www.sidimar.ipzs.it/fins012/docs/install.html, that probably 
looks scary for many potential users.

Now, moving out the block out of core will force us to make it easy to 
use externaly defined blocks. And that will make it much easier and more 
atractive for "outsiders" to develop blocks. And that will grow the 
community in a healthy and scalable way. It will also make the rest of 
"real blocks" (or maybe something else), a real itch to scratch and not 
just something that would be nice to have. I also believe that it will 
make us more motivated to make the core "lean and mean".

                                       --- o0o ---

So just throw the blocks out of core, we can solve the possible problems 
when and if they apear ;)

/Daniel



Mime
View raw message