cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] Finishing the first phase of block design
Date Thu, 09 Oct 2003 13:19:25 GMT

On Wednesday, Oct 8, 2003, at 04:50 Europe/Rome, Geoff Howard wrote:

> Stefano Mazzocchi wrote:
>> I have updated the block design documents on the wiki. Changes were:
> ...
>> A few things are left to decide:
>>  1) the block metadata information in the block.xml file
>>   see
>>  2) how blocks expose classloading to other blocks
>>                              - o -
>> Descriptive Block metadata
>> --------------------------
>> The descriptive block metadata that we currently include is:
>>  <name>***</name>
>>  <description href="...">***</description>
>>  <license href="..."/>***</license>
>>  <author href="...">***</author>
> +1
> Andreas suggested version number which is really handled already in 
> the block id and release date.  I think a date though may be a useful 
> additional piece of info.

Good point.

>> Ah, remember that "certification" or any other metadata on the 
>> "status" of the block is time dependent and therefore should *NOT* be 
>> included in this file.
> Yup.
>> Exposing classes
>> ----------------
>> Stephen proposed to separate the classes to expose in a different jar 
>> and expose that. I like this. It's simple and effective.
>> But instead of declaring classloaders or classpaths in the blocks, I 
>> propose to extend the block FS layout so that we have
>> for individual classes and resources:
>>  /classes
>>  /classes/public
>>  /classes/private
>> for jars:
>>  /lib
>>  /lib/public
>>  /lib/private
> Hmmm.  That is quite different than what one would expect from the WAR 
> paradigm, no?  Would
> COB-INF/[classes|lib]
> COB-INF/public/[classes|lib]
> or
> COB-INF/private/[classes|lib]
> COB-INF/public/[classes|lib]
> be any better?

This might suggest the concept that private is the location of all the 
things that are private so


means "I have libraries in the private section", so maybe I can put 
something else as well to have it protected? while


means "these are the private libraries"... but doesn't say anything 
about non-lib things. I still like this approach better, even if it 
moves away from the WAR paradigm (which is not a big deal, IMO, since 
blocks are different enough already)

>> the block manager will tranparently make available the classes found 
>> in the "public" folders to the blocks that depend on this block (and 
>> *ONLY* to those! classloading isolation is very important to achieve 
>> hot deployment functionality without impacting the performance of a 
>> running system too much)
> Is there never a way to avoid duplicating common jars between blocks?

Avoid? well, not architecturally, that could means weird classloading 

> I think we may be wise to go this way but I know this will be 
> unpopular and misunderstood and deserves some thought.

good point, though.

>> the classloader will also check for conflicts: in fact, it will be 
>> considered an error to depend on two blocks that provide one or more 
>> classes with the same absolute name.
> Hmmm.  not sure I can mentally eliminate all valid cases at this 
> stage.  Would there ever be an older version and a newer version of a 
> block deployed in the same space for example? (probably not but 
> thinking out loud)

Oh, yeah, the above "modulo versioning". If the same class applies in 
blocks that differ only for their versions, it's good. The problem is 
when two completely different blocks do. (we might signal a warning 
instead of an error, but that's an implementation detail).

> Exposing Resources
> ------------------
> I'm adding this because my brain is still a little unsure about this. 
> So far, we've said that file resources (an xsl for example)
> 1) need to be exposed via a sitemap pipeline, even if only by a reader
> 2) are not anywhere declared explicitly (except in the pipeline of 
> course)
> 3) are not distinguised from resources meant to be private by any 
> formal semantics, though this information could be conveyed 
> human-to-human in any block docs (blocs? blockumentation? ;) ).
> Here are my oustanding questions:
> - Will we regret requiring the overhead of pipeline setup (runtime I 
> mean) for blocks which expose a great deal of otherwise static 
> resources?

could be. remember though that the block: protocol will be caching 
friendly, so we might even gain performance.

> - Not found resources will have to go through every pipeline to 
> determine that it's not found.  With fallback behavior due to 
> polymorphism this gets worse.

I fail to see this, can you explain why you think this is the case?

> - Will not explicitly declaring which resources are meant to be public 
> cause trouble for block implementors and extenders?

?? well, in the sitemap I can be very precise on what I want to expose. 
and everything else is not exposed. the sitemap is like a virtual file 
system description, powerful enough to describe all possible systems.

If you have

<pipeline block-access="public">
  <match pattern="**">
   <read src="public/{1}"/>

than the contract moves at the file system level, but that's up to you 
to decide.... and a block extender can do

<pipeline block-access="public">
  <match pattern="stylesheet/layout2page.xslt">
   <generate type="sql" src="layout.xml"/>
   <transform src="layout2stylesheet.xslt"/>
   <serialize type="xml"/>

to provide extension that is procedural (but without exposing, for 
example layout.xml and layout2stylesheet.xslt which are just used 

With a single mechanism, it's much easier to do meaningful block 

> Of course the flexibility of decoupling the uri space from the 
> filesystem is a benefit - but is it necessary?

see above: I think so.

> How hard is it really to keep filenames and directory locations for a 
> selected group of public resources?

no, that's not the issue: the real issue is: if both resources and 
pipeline outputs are streams, why make a difference?


View raw message