cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geoff Howard <>
Subject Re: [RT] Finishing the first phase of block design
Date Wed, 08 Oct 2003 02:50:11 GMT
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>


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.

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


> 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




be any better?

> 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?  I 
think we may be wise to go this way but I know this will be unpopular 
and misunderstood and deserves some thought.

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

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?
- 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.
- Will not explicitly declaring which resources are meant to be public 
cause trouble for block implementors and extenders?

Of course the flexibility of decoupling the uri space from the 
filesystem is a benefit - but is it necessary?  How hard is it really to 
keep filenames and directory locations for a selected group of public 

Perhaps though there's a best of both worlds.  The last two issues may 
be answered by Stefan's sitemap access modifier RT?

Say "hi" to Ghent,

View raw message