Re: RT - Tree Traversal Implementation of Sitemaps and XSP

[Ovidiu Predescu <ov...@cup.hp.com>]

On Sat, 06 Oct 2001 14:24:05 +0200, Stefano Mazzocchi <st...@apache.org> 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.

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.

Besides, it would be nice to have this ability for completeness, for
the beauty of the architecture ;-).


Regards,
-- 
Ovidiu Predescu <ov...@cup.hp.com>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

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

Re: RT - Tree Traversal Implementation of Sitemaps and XSP

[Stefano Mazzocchi <st...@apache.org>]

Ovidiu Predescu wrote:
> 
> On Sat, 06 Oct 2001 14:24:05 +0200, Stefano Mazzocchi <st...@apache.org> 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
users.

Think about it.

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



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

Re: RT - Tree Traversal Implementation of Sitemaps and XSP

[giacomo <gi...@apache.org>]

On Sat, 6 Oct 2001, Ovidiu Predescu wrote:

> On Sat, 06 Oct 2001 14:24:05 +0200, Stefano Mazzocchi <st...@apache.org> 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.

Well, as Stefano pointed out I've never seen the need for it. We have an
application that has Cocoon acting as a SOAP server. And we never
encountered the need for dynamically generated pipelines. In contrary
the pipeline remains almost the same for every request. But this highly
depends on how Cocoon is acting as such a non-traditional server.

> 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 think here is the point! Generally passing SOAP documents between
pipelines isn't a thing we thought is practical. We instead pass normal
java objects processed by actions representing the service (or dispached
by it to components representing a service) to a pipeline which makes a
SOAP response out of it. This has (at least for us) the benefit using
"not so advanced and skilled" java programmers do a job in the web
service busines as well ;).

I've seen Berin evangelize the Axis community to use Avalon CM which I'd
like to see (I'm a totally Avalonist and all our projects are based upon
CM with Avalon because of the development speed we've gained using it).
It would make an integration into Cocoon very easy (well, this is a
guess). But they still are very resistent against :)

Using the Transformer approach for a web service makes it too much bound
to Cocoon (I know we have people here which like the custom Transformer
approach very well ;).

I see at least 80% of all SOAP services dealing with very little data on
the request side and thus it is practical to build a usual java object
out of it. Size is different on the response side but not that one need
a dynamically build pipeline. For the other 20% an approach spitting SAX
events directly from the SOAP document can make sense.

> Besides, it would be nice to have this ability for completeness, for
> the beauty of the architecture ;-).

Or FS ;)

Giacomo (which is now way off of the original issue of this thread :)


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