cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Mon, 08 Oct 2001 18:17:55 GMT
On Sun, 07 Oct 2001 23:48:10 +0200, Stefano Mazzocchi <> wrote:

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

Yes, the security aspect is something that needs to be kept in mind.

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

If the sitemap is no longer compiled, but instead created dynamically
as live objects, one could definitely create a new pipeline at runtime.

I'm not saying this is a useful feature, it's just that it should be
possible to do it. Now I'm sure a similar computation can be achieved
using a static pipeline, and probably this is the best way to do it in
most of the cases.

The example I had in mind could be implemented using a collection of
carefully designed static pipelines, I was just investigating the
option of a dynamically created pipeline. I'm not sure however it's
worth the trouble doing it so.

> 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
> users.
> Think about it.

I'm not sure I agree. A language provides the building blocks for
creating higher abstractions, and each language has its own
patterns. If Java had multiple inheritance, Avalon probably would look
very differently from today, but one way or another we would have
needed a framework to solve the same kind of problems.

Just as an aside note, I like Java without multiple inheritance ;-)

Best regards,
Ovidiu Predescu <> (inside HP's firewall only) (my SourceForge page) (GNU, Emacs, other stuff)

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

View raw message