Stefano Mazzocchi wrote:
This is a collection of (more or less) random thoughts about the implementation of Cocoon Blocks that I collected while talking with Ricardo and Sylvain IRL.
Please note that anything proposed here, while organic and workable, is not to be considered carved in stone, but rather a suggestion on how to move forward.
...
File System Layout and wiring data ----------------------------------
...
The deployment process added the mounting, wiring and configuration information
cob:mycompany.com/webmail/1.3.43 located at -> WEB-INF/blocks/384938958499 mounted on -> /mail/ "external-skin" -> cob:yetanothercompany.com/skins/fancy/1.2.2 "internal-skin" -> cob:mycompany.com/skins/corporate/34.3.345 "repository" -> cob:mycompany.com/repositories/email/exchange/3.2.1 configured as: user -> "guest" password -> "sj3u493"
cob:mycompany.com/repositories/email/exchange/3.2.1 located at -> WEB-INF/blocks/394781274834 configured as: host -> "mail.blah.org"
cob:yetanothercompany.com/skins/fancy/1.2.2 located at -> WEB-INF/blocks/947384127832
cob:mycompany.com/skins/corporate/34.3.345 located at -> WEB-INF/blocks/746394782637
the file system layout (relative to the cocoon webapp context) is
[-] WEB-INF
L___ [-] blocks
L___ wiring.xml
L___ [-] 384938958499
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of cob:mycompany.com/webmail/1.3.43)
L___ [-] 947384127832
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of cob:yetanothercompany.com/skins/fancy/1.2.2)
L___ [-] 746394782637
| L___ [-] BLOCK-INF
| | L___ block.xml
| L_ (the contents of cob:mycompany.com/skins/corporate/34.3.345)
L___ [-] 394781274834
L___ [-] BLOCK-INF
| L___ block.xml
L_ (the contents of cob:mycompany.com/repositories/email/exchange/3.2.1
where
wiring.xml contains the block IDs (which also identifies their location on disk) wiring, mounting and configurations.
block.xml contains the block metadata (which belong to the block and cannot be changed at deployment time).
NOTE: if the location path of the block is relative, it is searched by starting from the cocoon war context. The block content is *always* extracted from the archives and saves "as is" inside the folder.
NOTE (development time): in order to simplify block creation and development, it will be possible to explicity indicate the location of an already existing and extracted block implementation on disk. The block manager should also have autoreloading features (configurable, of course) that should reload the configurations, the wiring and the exposed components when they are changed.
...
Implementation Phases ---------------------
Phase 1: definition of the contract between the block manager inside cocoon and the standalone block deployer. These contracts include:
1) description of the file system layout (see above for a suggestion) 2) description of the wiring document schema 3) description of the block metadata schema
Ok, the file system seems fine - how about starting the discussion with the following for the wiring document? (I'm assuming stuff will have to change - just trying to get the ball rolling)
<?xml version="1.0" encoding="UTF-8"?>
<blocks version="1.0">
<block uri="cob:mycompany.com/webmail/1.3.43" wire-id="384938958499">
<mount>/mail/</mount>
<connections>
<connection
name="external-skin">cob:yetanothercompany.com/skins/fancy/1.2.2</connection>
<connection name="internal-skin">cob:mycompany.com/skins/corporate/34.3.345</connection>
<connection name="repository">cob:mycompany.com/repositories/email/exchange/3.2.1</connection>
</connections>
<configuration>
<param name="user">guest</param>
<param name="password">sj3u493</param>
</configuration>
</block>
<block uri="cob:mycompany.com/repositories/email/exchange/3.2.1" wire-id="394781274834">
<configuration>
<param name="host">mail.blah.org</param>
</configuration>
</block>
<block uri="cob:yetanothercompany.com/skins/fancy/1.2.2" wire-id="947384127832"/>
<block uri="cob:mycompany.com/skins/corporate/34.3.345" wire-id="746394782637"/>
</blocks>
Wiki'd here: http://wiki.cocoondev.org/Wiki.jsp?page=BlocksWiring
For sake of discussion, I recorded a wire-id instead of the location. Can blocks be in other locations other than WEB-INF/blocks/{$wire-id} ?
I also considered recording the wire-id instead of the uri for connections between blocks - what are the arguments for each?
<connection> was out of the blue using the wiring metaphore. Other options? Free association: connect, attach, solder, wire, use ...
Is it wise to limit configurations to name-value pairs, or should that allow arbitrary foreign xml markup?
For configuration, should a distinction be made between any create-time values and deploy-time values, or is that pointless once the wiring has happened?
For the wiring connections: should the matching uri even be recorded here, or only the role its looking for? (I think the uri, but just tossing out questions).
What blocks version is this? 1.0? 1.1? 2.1? 2.2?
Hack away, Geoff
