Re: Merging Stream And Event Pipeline

[Nicola Ken Barozzi <ni...@apache.org>]

From: "Carsten Ziegeler" <cz...@s-und-n.de>

> What do you all think about merging the stream and the event pipeline
> into one single interface/object?

You mean something like:

{
    String ROLE = "org.apache.cocoon.components.pipeline.Pipeline";

    boolean process(...)

    void setGenerator(...)
    void addTransformer(...)
    void setSerializer(...)

    void setReader(...)
 }


It could be ok, but since we're at it, why not make it better still.

8-B    <crazy-mode status="on"/>

An interface like the one above has the problem that setReader excludes the
use of other set* methods (even if the interface permits it), and that the
pipeline components have to be all set.

In essence the contract is bigger than the one the interface dictates.

The correct way IMHO, without thinking of the Avalon stuff, should be
something like:

{
    String ROLE = "org.apache.cocoon.components.pipeline.Pipeline";

    Pipeline(Generator, Transformer[], Serializer )
    Pipeline(Reader)

    boolean process(...)
 }

To make Cocoon able to make a pipeline of Readers (filtering), why not do:

{
    String ROLE = "org.apache.cocoon.components.pipeline.Pipeline";

    Pipeline(Generator, Transformer[], Serializer )
    Pipeline(Reader[])      <---------------------

    boolean process(...)
 }

We could do this:
 <map:pipeline>
    <map:read/>
    <map:read/>
    <map:read/>
 </map:pipeline>

To do this we should add a Filter:

public interface Filter extends
  SitemapModelComponent,
  SitemapInputComponent,    <------------------
  SitemapOutputComponent {

    String ROLE = "org.apache.cocoon.filtering.Filter";

    void setInputStream(...) <------------------
    void setOutputStream(...) <------------------
    void generate(...)
    long getLastModified(...)

}

and simply use Sources to get the streams.

We would have:
 <map:pipeline>
    <map:filter/>
    <map:filter/>
    <map:filter/>
 </map:pipeline>

You want something really whacky?
Here is what Cocoon should do IMHO to make all consistent:

Here it is:

<map:pipelines>
 <map:pipeline>
    <map:source/>
    <map:filter/>
    <map:filter/>
    <map:drain/>
 </map:pipeline>

 <map:pipeline>
    <map:source/>
    <map:filter/>
    <map:filter type="xml">
      <map:generate/>
      <map:transform/>

      <map:serialize/>
    </map:filter>
    <map:drain/>
 </map:pipeline>

> This would make the system less complex and reduce lookups per request
> as well.

good

> The splitting into those two objects was done to help implementing the
> cocoon: protocol. But AFAIK everywhere always those two objects are
> used in combination, even in the SitemapSource class implementing the
> cocoon: protocol.
>
> And as we want to make configurable pipelines for the next release,
> this would be easier to handle as well.

big +1 for configurable pipelines

--
Nicola Ken Barozzi                   nicolaken@apache.org
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------


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