cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: [RT] Finishing the first phase of block design
Date Sat, 04 Oct 2003 15:46:17 GMT

Stefano Mazzocchi wrote:

> Descriptive Block metadata
> --------------------------
> 
> The descriptive block metadata that we currently include is:
> 
>  <name>***</name>
> 
>  <description href="...">***</description>
> 
>  <license href="..."/>***</license>
> 
>  <author href="...">***</author>
> 
> where:
> 
>   *** -> short text
>   ... -> URL for reference
> 
> NOTE: I want to keep the above super simple. I know that <author> can be 
> generic and mapped to a person or group or entity... but at this point, 
> I think it's useless complexity.
> 
> This data will be used by the block librarian and by the block deployer 
> to catalogue and provide more information about this block. that's all.
> 
> I can't think of anything else I would like to know when choosing for a 
> block in a library of blocks.
> 
> 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.
> 
> If you think you'd need more info, this is a good time to speak up.

Don't know, if it fits into this file but here is some more information 
I can think of:
* Version number
* Release date

> 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
> 
> 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)
> 
> 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.
> 
> What do you think?

That's a very simple and easy-to-understand approach.
It does just what you need without hidden magic.
I like it :-)

> -- 
> Stefano.

Bye,
	Andreas


Mime
View raw message