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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
