Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 65492 invoked from network); 9 Sep 2003 17:00:48 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 9 Sep 2003 17:00:48 -0000 Received: (qmail 55888 invoked by uid 500); 9 Sep 2003 16:59:01 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 55750 invoked by uid 500); 9 Sep 2003 16:58:59 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 55698 invoked from network); 9 Sep 2003 16:58:59 -0000 Received: from unknown (HELO host.leverageweb.com) (64.91.232.157) by daedalus.apache.org with SMTP; 9 Sep 2003 16:58:59 -0000 Received: from dhcp205059.hq.af.mil ([134.205.205.59] helo=leverageweb.com) by host.leverageweb.com with asmtp (Exim 3.36 #1) id 19wkA0-0003YH-00 for dev@cocoon.apache.org; Tue, 09 Sep 2003 11:12:04 -0400 Message-ID: <3F5DEE5D.70106@leverageweb.com> Date: Tue, 09 Sep 2003 11:14:37 -0400 From: Geoff Howard User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425 X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Implementing Cocoon Blocks References: <3F4F728F.2050203@verizon.net> <3F4F7C20.9060709@leverageweb.com> <3F4F7EE7.2010604@verizon.net> <3F501293.4030502@leverageweb.com> <1063118895.22515.338.camel@yum.ot> In-Reply-To: <1063118895.22515.338.camel@yum.ot> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host.leverageweb.com X-AntiAbuse: Original Domain - cocoon.apache.org X-AntiAbuse: Originator/Caller UID/GID - [0 0] / [0 0] X-AntiAbuse: Sender Address Domain - leverageweb.com 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 Bruno Dumon wrote: > On Sat, 2003-08-30 at 04:57, Geoff Howard wrote: > > >>But this brings up another point - what to do if the wiring.xml and >>others is deleted? Presumably, all blocks are "uninstalled" in this >>state, but what does this do to persistence requirements. >> >>Also, how to recreate the deploy step efficiently? For example: >> >>You deploy a block with some dependencies and configuration. The block >>deploy process walks you through setting configs and resolving >>dependencies. You then have no record of these deployment choices >>except in wiring.xml which is not meant for human consumption. Perhaps >>it would be good to record these human-step deployment time >>configurations in a conf file which could be easily reprocessed to >>easily re-deploy all blocks to their last configuration. > > > I think the conf file you're speaking of here is simply the wiring.xml > file itself? Remember, the block deployer has read-write access to this > file, so it can first read the existing information, then let the > administrator modify it, and then write it back. It's not like each time > you want to modify the configuration of one block you'll have to > re-enter all the parameters for other blocks as well. Ugh, I see now that I didn't explain well the scenario I was thinking of and now can't remember! IIRC I was trying to think through the process of replication and/or staging. In this case, would I copy over wiring.xml and all blocks directories? (presumably) But, what if some of the deploy-time configurations need to change on the way? For instance, on a staging server, you use a different database. So, I was just trying to get a picture in my head of how that would work and what the pitfalls were. Geoff