Return-Path: 
 <dev-return-47545-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 74570 invoked from network); 9 Sep 2003 14:36:40 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 9 Sep 2003 14:36:40 -0000
Received: (qmail 17604 invoked by uid 500); 9 Sep 2003 14:36:22 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 17580 invoked by uid 500); 9 Sep 2003 14:36:22 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 17536 invoked from network); 9 Sep 2003 14:36:21 -0000
Received: from unknown (HELO otsrv1.iic.rug.ac.be) (157.193.121.51)
  by daedalus.apache.org with SMTP; 9 Sep 2003 14:36:21 -0000
Received: from yum.ot (host100 [192.168.123.100])
	by otsrv1.iic.rug.ac.be (8.11.6/8.11.6) with ESMTP id h89Dl3X16774
	for <dev@cocoon.apache.org>; Tue, 9 Sep 2003 15:47:03 +0200
Subject: Re: [RT] Implementing Cocoon Blocks
From: Bruno Dumon <bruno@outerthought.org>
To: dev@cocoon.apache.org
In-Reply-To: <3F4ECE25.9020902@leverageweb.com>
References: <4CD93AAB-D0D4-11D7-A92A-000393D2CB02@apache.org>
	 <3F4ECE25.9020902@leverageweb.com>
Content-Type: text/plain
Organization: Outerthought
Message-Id: <1063114912.22515.277.camel@yum.ot>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.4 
Date: Tue, 09 Sep 2003 15:41:53 +0200
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N
X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N

(catching up on block discussions...)

On Fri, 2003-08-29 at 05:53, Geoff Howard wrote:
<snip/>
> > 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 ...

Avalon Phoenix uses the words "assembly" and "provide" instead of
"wiring" and "connection", which I quite like (I mean the assembly &
provide).

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org                          bruno@apache.org