Return-Path: 
 <dev-return-58559-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@www.apache.org
Received: (qmail 21702 invoked from network); 31 Mar 2004 18:45:07 -0000
Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12)
  by minotaur-2.apache.org with SMTP; 31 Mar 2004 18:45:07 -0000
Received: (qmail 38681 invoked by uid 500); 31 Mar 2004 18:44:54 -0000
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 38641 invoked by uid 500); 31 Mar 2004 18:44:53 -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 38609 invoked from network); 31 Mar 2004 18:44:53 -0000
Received: from unknown (HELO pulse.betaversion.org) (62.140.213.123)
  by daedalus.apache.org with SMTP; 31 Mar 2004 18:44:53 -0000
Received: (qmail 14262 invoked from network); 31 Mar 2004 18:44:55 -0000
Received: from unknown (HELO ?217.158.110.71?) (pier@217.158.107.35)
  by pulse.betaversion.org with SMTP; 31 Mar 2004 18:44:55 -0000
Mime-Version: 1.0 (Apple Message framework v613)
In-Reply-To: 
 <1E0CC447E59C974CA5C7160D2A2854EC02FECD03@SJMEMXMB04.stjude.sjcrh.local>
References: 
 <1E0CC447E59C974CA5C7160D2A2854EC02FECD03@SJMEMXMB04.stjude.sjcrh.local>
Content-Type: text/plain; charset=US-ASCII; format=flowed
Message-Id: <7F4E7233-8343-11D8-BAAE-000393427116@betaversion.org>
Content-Transfer-Encoding: 7bit
From: Pier Fumagalli <pier@betaversion.org>
Subject: Re: [Kernel2.2] Comments
Date: Wed, 31 Mar 2004 19:44:52 +0100
To: dev@cocoon.apache.org
X-Mailer: Apple Mail (2.613)
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

On 31 Mar 2004, at 18:43, Hunsberger, Peter wrote:
> Leo Sutic <leo.sutic@inspireinfrastructure.com> writes:
>
> <big snip/>
>
>> My whole argument is that your design will end up being very very
>> complicated and very very hard to develop for, since it
>> provides so few
>> guarantees to block developers. Things like "what code is
>> running", for
>> example.
>
> So if you've got something for which blocks are not suited (like 
> perhaps
> SSL, or a DB pool), don't use blocks; use modules or whatever it is 
> that
> does give you the contract you want.  The rest of Cocoon isn't going
> away...

Well, I'm actually using the framework to build two things for my 
employer: an XML repository backed up by a DataBase (connection pooling 
and JDBC connections flying all around) and a HTTP/HTTPS NIO based 
(possibly with ESI support) proxy server that we're going to use as a 
Cocoon-frontend.

I'll need to come up with some block examples soon before being so 
misunderstood! :-)

	Pier