Return-Path: Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org Received: (qmail 36260 invoked by uid 500); 5 Apr 2002 17:17:27 -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 36249 invoked from network); 5 Apr 2002 17:17:26 -0000 Message-ID: <002901c1dcc5$5b51a570$670004c0@PC103> Reply-To: "Nicola Ken Barozzi" From: "Nicola Ken Barozzi" To: References: <3CADD659.F9A928AF@apache.org> Subject: Re: [status & RT] design challenges Date: Fri, 5 Apr 2002 19:14:34 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Stefano Mazzocchi" > My impression is that pipe-aware selection is 'forcing' metadata to pass > 'thru' the pipeline while it doesn't really make sense to do so. > > So, IMO, there must be some transformers that obtain the required > selection information from the pipeline, place it somewhere else > (probably someplace in the object model) and have the selectors look at > those 'parallel signals' without having to mess with the pipeline. Bud don't Selectors get to run *before* Transformers. This is the whole point it seems. It's not a matter of how, but when. Selectors can run after Transformers only if another pipeline is called, and this will basically force you to use the flow pipeline for this, since in fact it's flow we're talking about. As I see it, Matchers, Selectors and stuff can easily be put all in the flow part, but this makes Cocoon too "procedural". An easy tip: if you serve web pages, use the pipeline only. If you need to make complex decisions and procedures on the flow, use the flowmap. > So, I restate my -1 on pipe-aware selection and I propose the creation > of a 'parallel transport layer' between components that is based on > objects and not SAX events. Could you elaborate more on this? I think it's something like having a request object, but seen as a parallel pipeline. I'm +1000 on this, since it finally fullfilles the original intention we had with Cocoon2 pre-alpha to have a parallel metadata pipeline, where there are also notifications. Gee, it seems that you saw right before needing it! :-O :-) -- Nicola Ken Barozzi nicolaken@apache.org - verba volant, scripta manent - (discussions get forgotten, just code remains) --------------------------------------------------------------------- --------------------------------------------------------------------- To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org For additional commands, email: cocoon-dev-help@xml.apache.org