cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject [RT] Finishing the first phase of block design
Date Fri, 03 Oct 2003 15:20:08 GMT
I have updated the block design documents on the wiki. Changes were:

  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.


Mime
View raw message