1) change /BLOCK-INF/ to /COB-INF/
2) change "cob:" back to "http:" for block URIs
[which URI range to use for blocks doesn't need to be identified at this point, even if Ugo's suggestion to use http://cocoon.apache.org/blocks is a good one so that it separates naturally namespaces URIs from block URIs]
- o -
A few things are left to decide:
1) the block metadata information in the block.xml file
see http://wiki.cocoondev.org/Wiki.jsp?page=BlocksCob
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>
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.
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?
-- Stefano.
