Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 61785 invoked from network); 23 Jul 2004 08:23:27 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 23 Jul 2004 08:23:27 -0000 Received: (qmail 99237 invoked by uid 500); 23 Jul 2004 08:23:23 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 99163 invoked by uid 500); 23 Jul 2004 08:23:23 -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 99150 invoked by uid 99); 23 Jul 2004 08:23:22 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [195.144.64.135] (HELO smtp1.xs4all.be) (195.144.64.135) by apache.org (qpsmtpd/0.27.1) with ESMTP; Fri, 23 Jul 2004 01:23:20 -0700 Received: from [192.168.123.113] (195-144-088-017.dyn.adsl.xs4all.be [195.144.88.17]) (authenticated bits=0) by smtp1.xs4all.be (8.12.10/8.12.10) with ESMTP id i6N8NDYN029160 for ; Fri, 23 Jul 2004 10:23:14 +0200 Message-ID: <4100CAF1.40705@outerthought.org> Date: Fri, 23 Jul 2004 10:23:13 +0200 From: Marc Portier Organization: Outerthought User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: [RT] Virtual Sitemap Components References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Carsten Ziegeler wrote: > Sylvain Wallez wrote: > > >>So let's recap what's allowed where: >>- in virtual generators, transfomers, serializers >>(SAX-oriented VPCs): >>match, select, act but no redirect. redirect-to and call are >>forbidden. > > Yepp. > > >>- in virtual readers: everything is allowed. >> >>Is that ok? >> > > What is the use-case for a virtual reader? > virtual-readers is just nomenclature ATM today's resources can behave like any of 4 things 1. a generator + transformers --> virtual transformer 2. a set of transformers --> virtual transformer 3. a set of transformers terminated with a serializer --> virtual serializer 4. a full pipe from generator to serializer --> virtual reader? > Isn't a enough? > there is a bit of nuance here in how you pass parameters, no? > And if that's not good, you can simply call a resource. > sure, I only got the feeling (expressed before) that the VPC move sounds like more strongly specifying which kind of resource you have... not to be mixing with the nowadays 'it could be anything' resource the term 'virtual reader' would be to the reader what the virtual generator is to the generator: a declaratively composed pipeline-compont with a predictable nature of being? (ie what is lacking in resources) as such I catched at a certain moment during the discussion that we would deprecate resources as a whole but keep on supporting and start promoting the switch to the more solid virtual-xxx thingies... HTH regards, -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ mpo@outerthought.org mpo@apache.org