cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [design] Cocoon Blocks 1.1
Date Sun, 03 Nov 2002 22:14:00 GMT
Ovidiu Predescu wrote:

> 1. I definitely agree with Sylvain's view of blocks as classes, not as
> instances. I think is important to expose pipelines and not individual
> resources. Sylvain explained to me why this is important when it came to
> the control flow layer, which now uses only pipelines and not resources.

Yes, I agree.

> 2. Another question is how are we dealing with flow scripts? Are we
> going to expose functions on a per-block level?
> Or we consider flows as resources of the block, hence hidden from the
> user, and accessible only through pipelines publicly exposed?

Yes, I like this one better as well.

> I would favor the latter, as it's in line with the pipelines idea
> Sylvain mentioned.
> 3. What is the relationship between libraries defined in a block and
> those defined in the container loading it? Are they loaded by the same
> classloader or by different classloaders?

Different classloaders, I would presume.

> I think the latter would help isolate contracts between different
> blocks, at the risk of duplicating libraries in the runtime system.  

Yep, I'd like use a little more memory than having a bunch of class 
versioning conflicts down the road. RAM is way cheaper than users's time 
(and patience!)

> The
> impact should be minimal however in real life, with different blocks
> serving different purposes (FO generation etc.).

Yes, exactly. Also, the container should come with a minimal set of 
libraries installed, and also we need separate classloaders because two 
blocks could be using two different versions of the same block for bug 

> Coupled with the exposure of pipelines only, block contracts are then
> well defined and separated.


Stefano Mazzocchi                               <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message