Return-Path: 
 <cocoon-dev-return-25221-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 99768 invoked by uid 500); 5 Apr 2002 10:38:12 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 99757 invoked from network); 5 Apr 2002 10:38:11 -0000
Message-ID: <3CAD7E9E.1050002@nada.kth.se>
Date: Fri, 05 Apr 2002 12:38:22 +0200
From: Daniel =?ISO-8859-1?Q?Fagerstr=F6m?= <danielf@nada.kth.se>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
 rv:0.9.2) Gecko/20010726 Netscape6/6.1
X-Accept-Language: sv, en-us
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [SUMMARY] Viva la Multiplexer! (was:  [Contribution] Pipe-aware
 selection)
References: <002101c1dc17$27979a90$5d6363c0@YEAGAR>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Greg Weinger wrote:
<snip/>

> To summarize, Vadim proposed his Multiplexer idea as a better solution than
> pipe-aware selection.  Stefano agreed, thought the idea more elegant,
> but asked for a recap of the issues, and a specific proposal from Vadim.

I'd love to have a Multiplexer component in Cocoon. I'd like Cocoon 
develop to the point where you can build webapps as easy and as elegant 
as you can build webpublishing today. I belive that one important part 
in achieving this goal is to be able to do most of the things that you 
have to write special pupose actions for today, to reusable pipeline 
components. IMO a Multiplexer have an important role to fill in this 
scenario, and so has pipe-aware selection.

A selector choose _one_ of several processing paths for the input 
stream, while IIUC a multiplexer (at least conceptually), make several 
copies of the input stream, put each copy in a xpath-based filter that 
takes out a part of the stream and send it to a sub-pipeline, and in the 
end the filtered and processed streams are recombined to one single 
stream. IMO these are to different concern ares and I can't see any 
advantages in combining it to one component. Yes, I'm aware that you can 
  do pipe-aware selection in a multiplexer by making the filter xpaths 
mutually exclusive, so that only one of the sub-pipes are used:

<multiplex>
   <part xpath="a and not(b) and not(c) and not(d)">
     <!-- sub pipe -->
   </part>
   <part xpath="not(a) and b and not(c) and not(d)">
     <!-- sub pipe -->
   </part>
   <part xpath="not(a) and not(b) and c and not(d)">
     <!-- sub pipe -->
   </part>
   <part xpath="not(a) and not(b) and not(c) and d">
     <!-- sub pipe -->
   </part>
</multiplex>

I fail to find that particular usage of multiplexing elegant. It also 
seem higly non-trivial to write a multiplexer component that is 
efficient in the above scenario. Negations in xpaths are somewhat tricky 
beasts: <retoric-question>how much of the input stream do you need to 
scan (and buffer) before you know that "not(//elem)" is 
true?</retoric-question>

IIRC there were never any concrete design propopsals in the multiplexer 
discussion and there is an implementation (although with some rough 
edges) of a pipe-aware selector, IMHO that is a not completely neglible 
difference between the two proposals ;)


<snip/>
> To be honest, I haven't looked at Daniel's new selection code,

Please take a look at it, it is not much code at all, it is quite 
straight forward and I even added a few cryptic comments and wrote a 
README-file to the code ;)

> but from the description, given its use of DOM and additional pipeline
> generation, I still think Vadim's Multiplexer proposal comes out ahead
> in terms of elegance and performance.  Plus it has more use cases than
> simple pipeline dispatching.

See above. IMHO it is not a question about multiplexing vs pipe-aware 
selection, we need booth.
I know that there have been a lot of concern about that a DOM-based
pipe-aware selection mechanism would be a performance bottleneck, but:
* Pipe-aware selection will not affect your performance if you don't use
it.;)) The only extra cost in the selector mechanism is a test if the 
PipeAware interface is implemented of the selector.
* The main use case is input handling, and input is typically quite 
small amount of data.
* Input is often put in databases, or used as input for some business 
components in that context DOM-tree construction is a minor cost.
* Schematron validation e.g., requires DOM-input anyhow.
Of course there might be use cases for pipe-aware selection where a DOM
based implementation would be a major performance bottleneck, but untill
we have seen that it seem IMHO unnecessary to do lots of complicated 
optimizations.

<rant>
I'm somewhat amused, some of you guys seem obsesed by DOM hatred. I 
really appriciate your work for exorcising DOM from web publishing, but 
I think webapps are somewhat different, and I have written quite a lot 
about in what way on the list. With a few exceptions (thank you Stefano 
and Ivelin) all response I get is: he have used the D-word, Thou shall 
never use DOM in Cocoon. ;)
I don't remember who wrote that: "premature optimzation is the root of 
all evil".
</rant>

/Daniel Fagerstrom

 



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org