On Friday, Aug 29, 2003, at 05:53 Europe/Rome, Geoff Howard wrote:
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)
Ok, great. Does anybody have a problem with the proposed file system layout?
<?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} > ?
potentially, yes. Sylvain suggested that, during block development, you might want to keep the block in the directory you are used to and have cocoon point to that, instead of having to copy it there everytime.
so, you need to add a block/@location attribute (preferred over an element, because a block can have one and only one location)
I also considered recording the wire-id instead of the uri for connections between blocks - what are the arguments for each?
wire-id is an artifact created by the deployment manager but doesn't add information to the wiring schema:
<blocks xmlns="http://apache.org/cocoon/blocks/wiring/1.0";>
<block id="cob:mycompany.com/webmail/1.3.43">
<location>WEB-INF/blocks/384938958499</location>
<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>
<configurations>
<param name="user">guest</param>
<param name="password">sj3u493</param>
</configurations>
</block>
<block id="cob:mycompany.com/repositories/email/exchange/3.2.1"> <location>WEB-INF/blocks/394781274834</location> <configurations> <param name="host">mail.blah.org</param> </configuration> </block>
<block id="cob:yetanothercompany.com/skins/fancy/1.2.2"> <location>WEB-INF/blocks/947384127832</location> </block>
<block id=cob:mycompany.com/skins/corporate/34.3.345"> <location>WEB-INF/blocks/746394782637</location> </block>
</blocks>
Rationale for this:
1) there could be many blocks
2) there can be only one block with the give URI in the system (so the use of '@id' is meaningful also from an XML perspective)
3) the wire-id number is not semantically meaningful from a block perspective, it's simply autogenerated by the deployment tool, but location can be arbitrary and block URI are already uniquely idenfitying the block
4) changed "configuration" in "configurations" to identify a container that can contain one or more parameters.
<connection> was out of the blue using the wiring metaphore. Other options? Free association: connect, attach, solder, wire, use ...
I have no problems with this.
Is it wise to limit configurations to name-value pairs, or should that allow arbitrary foreign xml markup?
No, name-value pairs is fine. Everything else would be too hard to configure at runtime and block shouldn't need too many parameters for configuration at deployment time.
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?
that section will only contain deploy-time values. create-time values will be included in the block.xconf, which is the block equivalent of cocoon.xconf (and will be full xml configurations)
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).
yes, both name and URI are required to fully identify the wiring.
What blocks version is this? 1.0? 1.1? 2.1? 2.2?
Following namespace URI versioning conventions, I would say "1.0" since it's the first release of such a schema.
- Stefano.
