Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <3F4ECE25.9020902@leverageweb.com>
Date: Thu, 28 Aug 2003 23:53:09 -0400
From: Geoff Howard <cocoon@leverageweb.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.3.1) Gecko/20030425
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: [RT] Implementing Cocoon Blocks
References: <4CD93AAB-D0D4-11D7-A92A-000393D2CB02@apache.org>
In-Reply-To: <4CD93AAB-D0D4-11D7-A92A-000393D2CB02@apache.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Getting the ball rolling on Phase One...

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