cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Greg Weinger" <gwein...@itmedicine.net>
Subject RE: [SUMMARY] Viva la Multiplexer! (was: [Contribution] Pipe-aware selection)
Date Fri, 05 Apr 2002 20:55:11 GMT
> From: Daniel Fagerström [mailto:danielf@nada.kth.se] 
<snip/>
> 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.

Right on!

> 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. 

Don't know about those implementation details, but you're right,
multiplexing fulfills a different need, for which I aim to contribute my
own little monster soon, which unfortunately uses caching instead of
true event forwarding.

>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. 

Doesn't exactly put the best face on it ;)  
I agree that this use is a hack, but I was imagining more trivial cases:

 <multiplex>
    <part xpath="/output/noresults" src="cocoon:/noresultspage" />
    <part xpath="/output/results" src="cocoon:/resultsview"/>
 </multiplex>

Not so hideous anymore, is it? 

> 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>

Agreed.

> 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 ;)
 
I know :/  That's why I was trying to stir the pot, and help any way I
can.
 
> <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 ;)

I will, I promise. 

> <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>

Rant well taken :)  Thank you all for opening my eyes. 



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


Mime
View raw message