cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Sun, 07 Oct 2001 21:48:10 GMT
Ovidiu Predescu wrote:
> On Sat, 06 Oct 2001 14:24:05 +0200, Stefano Mazzocchi <> wrote:
> > Peter Royal wrote:
> >
> > > One new feature i'd love to see is the construction of dynamic pipelines. I
> > > have a hack for this in my own code right now as a transformer which
> > > creates its own mini-pipeline inside of itself.
> >
> > Even if runtime sitemap tree travesal will make easier to implement
> > this, I keep on being against such an approach even if I had the
> > temptation myself to use something equivalent.
> >
> > The reason: it breaks separation of concerns because the sitemap
> > administrator and the programmers that generates the code that generates
> > the dynamic pipeline must be the same person or must overlap completely.
> >
> > Also, I've never seen a case where the need for dynamically generated
> > pipelines could not be solved with more carefully designed static
> > pipelines.
> >
> > However, if you have any example that proves me wrong, I'll be happy to
> > reconsider my position.
> This would probably be needed when Cocoon is used in non-traditional
> ways. One can use Cocoon to transform arbitrary SOAP messages
> (e.g. Cocoon IS the SOAP server), where the decision of how the
> pipelines look like is not known until at runtime.

I don't like this: I'm all for making cocoon powerful enough to be able
to do a bunch of things, but this clearly appears to me as flexibility
syndrome and a very dangerours potential security problem.

> Now one can start thinking of all the possible combinations of
> pipeline components, and put them in the static sitemap. But this
> would make the sitemap look very ugly, and maybe difficult to pass
> SOAP documents between pipelines.

I disagree: allowing the SOAP request to drive the pipeline composition
might reduce the configuration effort on your side, but might leave too
much freedom to the SOAP requestor.

Anyway, I will not accept to discuss this on a theorical base, but based
on real-life examples since I have the impression yours is just a call
for what you call "completness" below, but such search for the ultimate
feature is something that normally does more harm than good.
> Besides, it would be nice to have this ability for completeness, for
> the beauty of the architecture ;-).

I'm sorry, but I don't consider something more beautiful just because if
you do one and two, and you could do n, you should.

Java *could* have implemented multiple class inheritance, but if it had,
we wouldn't have came up with Avalon and behavior-driven components, nor
we would be so inclined to think twice before adding some more
complexity to a system.

Expecially if this system is highly nonlinear, like a community of

Think about it.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

To unsubscribe, e-mail:
For additional commands, email:

View raw message