accessing the pipeline structure

[Jorg Heymans <jh...@domek.be>]

Hi,

Recently there were 2 requests on the users list about accessing the 
current pipeline structure.

http://marc.theaimsgroup.com/?t=109448337100002&r=1&w=2
http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109473546831881&w=2

What does the devlist think about this? Certainly cocoon is being 
stretched in all areas possible, having the need for metadata about the 
executing pipeline structure is just one example of this.

Having this extra metadata would allow for components that can produce 
different output depending on how they are used in a pipeline (but this 
probably breaks a few cocoon design rules right?). In my cocoon video 
rendering application i got around this by creating an xml control 
structure that was used by all components, so a component could find out 
what all previous components did and what the results were.

Thoughts? Is this difficult to implement? A 2.2 feature perhaps?

Jorg

Re: accessing the pipeline structure

[Jorg Heymans <jh...@domek.be>]

Stefano Mazzocchi wrote:


<snip/>

> 
> 
> This smells awefully close to "dynamic pipelines" which is something 
> that is considered an anti-pattern in cocoon (because it has been tried 
> in the 1.x generation and miserably failed).
> 
> People see the pipeline machinery and think they can do things like SOAP 
> validation with it... well, it's not designed for that.
well that's what happens when people find a shiny new hammer - all they 
see are nails :)

> 
> A while ago there was the proposal of "content-aware selectors" that 
> would allow you to implement what these guys want, I know that there is 
> also an implementation floating around even if we never reached 
> consensus on whether or not that was a good thing to have.
> 
> What you are proposing is "context-dependent behavior"... well, this is 
well it's context-dependent behavior yes - but implemented in a context 
independent way.

> *exactly* what we are trying to avoid with pipelines: reusability of the 
> component is focused to be completely independent of the place where it 
> is used in the pipeline. Make the component "location dependent" and 
> kiss goodbye to orthogonality, and pretty soon you need a language that 
wasn't the guy trying to achieve the opposite? He wanted to be develop a 
component that he could plug anywhere because it autonomously finds out 
about the pipeline structure it's embedded in. Is that then "location" 
dependent because it needs to find out about it's location or "location 
independent" because it finds out about it's location and acts 
automagically. I'm confused now.

> indicates the potential 'neightbours' of each component... and maybe 
> people would want to add conditionals to that language... and pretty 
> soon people will ask you to deparate the cross-cutting pipeline concerns 
> into pipeline interceptors... and so on.
i see your point though here.

Regards
Jorg

Re: accessing the pipeline structure

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

Jorg Heymans wrote:

> Hi,
> 
> Recently there were 2 requests on the users list about accessing the 
> current pipeline structure.
> 
> http://marc.theaimsgroup.com/?t=109448337100002&r=1&w=2
> http://marc.theaimsgroup.com/?l=xml-cocoon-users&m=109473546831881&w=2
> 
> What does the devlist think about this? Certainly cocoon is being 
> stretched in all areas possible, having the need for metadata about the 
> executing pipeline structure is just one example of this.
> 
> Having this extra metadata would allow for components that can produce 
> different output depending on how they are used in a pipeline (but this 
> probably breaks a few cocoon design rules right?). In my cocoon video 
> rendering application i got around this by creating an xml control 
> structure that was used by all components, so a component could find out 
> what all previous components did and what the results were.
> 
> Thoughts? Is this difficult to implement? A 2.2 feature perhaps?

This smells awefully close to "dynamic pipelines" which is something 
that is considered an anti-pattern in cocoon (because it has been tried 
in the 1.x generation and miserably failed).

People see the pipeline machinery and think they can do things like SOAP 
validation with it... well, it's not designed for that.

A while ago there was the proposal of "content-aware selectors" that 
would allow you to implement what these guys want, I know that there is 
also an implementation floating around even if we never reached 
consensus on whether or not that was a good thing to have.

What you are proposing is "context-dependent behavior"... well, this is 
*exactly* what we are trying to avoid with pipelines: reusability of the 
component is focused to be completely independent of the place where it 
is used in the pipeline. Make the component "location dependent" and 
kiss goodbye to orthogonality, and pretty soon you need a language that 
indicates the potential 'neightbours' of each component... and maybe 
people would want to add conditionals to that language... and pretty 
soon people will ask you to deparate the cross-cutting pipeline concerns 
into pipeline interceptors... and so on.

we *already* have clear separation, let's not ruining it.

Now, the guy needs a SOAP validator transformer. My suggestion would be 
*NOT* to reuse the cocoon pipeline machineries for that but to just call 
something else that does it for you, like Axis, or write his own 
reactor-based valication code in flowscript calling Axis stuff.

-- 
Stefano.