Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 31562 invoked by uid 500); 28 Jun 2003 08:50:49 -0000 Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: cocoon-dev@xml.apache.org Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 31549 invoked from network); 28 Jun 2003 08:50:49 -0000 Received: from anchor-post-39.mail.demon.net (194.217.242.80) by daedalus.apache.org with SMTP; 28 Jun 2003 08:50:49 -0000 Received: from media.demon.co.uk ([80.177.14.141]) by anchor-post-39.mail.demon.net with esmtp (Exim 3.36 #2) id 19WBQD-0005qr-0U for cocoon-dev@xml.apache.org; Sat, 28 Jun 2003 09:51:01 +0100 Date: Sat, 28 Jun 2003 09:50:58 +0100 Subject: Re: [Flow] Calling internal-only pipelines Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Jeremy Quinn To: cocoon-dev@xml.apache.org Content-Transfer-Encoding: quoted-printable In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.552) X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Friday, June 27, 2003, at 05:48 PM, Stefano Mazzocchi wrote: > on 6/27/03 4:25 AM Jeremy Quinn wrote: > >> On Friday, June 27, 2003, at 06:48 AM, Reinhard P=F6tz wrote: >> >> >>> One of the open issues of flow is that we can't send "internal-only" >>> pipelines at the moment. >>> >>> If we call sendPage( uri, bizData) from the flow layer the forwardTo >>> of the AbstractInterpreter is called which performs a redirect using >>> the Redirector. >>> >>> Does anybody with more in-depth knowledge have an idea what we can = do >>> to >>> >>> enable the flow sending internal-only pipelines in the future? >> >> >> Should this not be enforced rather than just be an option? >> >> ie. sendPage*() should _only_ be able to call internal-only = pipelines, >> whereas redirect() can only go to "external-only" ones. > > We discussed this already and decided not to enforce it because there > could be services that are publicly available and then wrapped by the=20= > flow. Sorry .... I had forgotten .... > For future "real block" this might well be a common scenario. It all comes flooding back ;) > As for redirect(), redirecting to an internal-only pipeline will > obviously fail already, we don't have to enforce that. for sure > As for implementing this, I planned to look into this today. Great! regards Jeremy