Return-Path: Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 99304 invoked by uid 500); 4 Jul 2003 16:29:20 -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 99289 invoked from network); 4 Jul 2003 16:29:20 -0000 Received: from 66.111.0.243.nyinternet.net (HELO confixx.bestiole.ch) (66.111.0.243) by daedalus.apache.org with SMTP; 4 Jul 2003 16:29:20 -0000 Received: from codeconsult.ch (lsb-catv-5-p181.vtxnet.ch [212.147.120.181]) by confixx.bestiole.ch (8.11.6/8.11.6) with ESMTP id h64GTKS20048 for ; Fri, 4 Jul 2003 18:29:20 +0200 Date: Fri, 4 Jul 2003 18:29:20 +0200 Subject: Re: [RT] Generalizing the flow Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Bertrand Delacretaz To: dev@cocoon.apache.org Content-Transfer-Encoding: quoted-printable In-Reply-To: <3F05A520.2070400@anyware-tech.com> Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Le Vendredi, 4 juil 2003, =E0 18:02 Europe/Zurich, Sylvain Wallez a = =E9crit=20 : > ...Now things can be different, however, for implementations that use=20= > the same high-level concepts (a flow engine or a ServerPages=20 > generator) but a different approach, such as flow engines driven by an=20= > existing back-end... wow - Flow engines driven by external back-ends....this opens up a=20 whole new set of (realistic and useful) possibilites. > .... But these ones will be application-specific and won't be present=20= > in Cocoon's CVS. But the important point is that Cocoon should not=20 > prevent them to exist where needed.... Yes! Interfaces, it's all about interfaces. Having a clean abstract interface to the Flow engine will be a Good=20 Thing, thanks Sylvain and Marc for your analysis! -Bertrand