Daniel Fagerström wrote:
>
> 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.
We all want this. But I *DO*NOT* want to start tweaking the sitemap
elegance before the flowmaps are implemented.
My personal perception is that we are using the 'hammer antipattern'
here: the sitemap is the hammer, and everything looks like a nail.
Pipe-aware selection triggers these thoughts in my mind.
> 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.
hmmm...
> 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.
I agree on this.
> 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.
I guess it's hard to disagree here :)
> 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>
Right.
> 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.
For sure we need more symmetry and more functionality in the pipelines.
If multiplexing and pipe-aware selection are the way to implement them
is yet to be understood.
> 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>
Agreed. My concerns are *not* implementation-wise, I'm *never* concerned
by implementations because a community can always make it better.
I'm concerned by architecture design because I don't think that it's
equivally easy to progressively refine an architecture, expecially when
you need to provide back compatibility from each incremental step.
It's easy to add stuff, much easier than *not* to add stuff.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
