cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <>
Subject Re: [RT] Input Pipelines (long)
Date Mon, 23 Dec 2002 09:56:14 GMT

(my comments, based on the discussions that are going on lately and my 
work on the blocks move and doc writing)

Stefano Mazzocchi wrote:
>> If we compare a Cocoon output pipeline with a unix pipeline, it always
>> ignore standard input and always write to standard output.
> Sorry, but this is plain wrong.
> Cocoon already ships generators that do *NOT* ignore the request input. 

Look at the Request interface.
There is no method to get the input.

> Extending those components to perform higher-level functionality is 
> *NOT* an architectural problem. Or at least, I don't see why it should be.

If a Request has input, we should at least put it in the interface.

Vadim has proposed, after some discussion, to add the possibility of 
returning n streams, that can be used for example in mails or in any 
system that inputs multitype data.

>> In a servlet, input would be
>> taken from the input stream of the request object. We could also have
>> a writable cocoon: protocol where the input stream would be set by the
>> user of the protocol, more about that later, (see also my post in the
>> thread [1]).
>> An example:
>> <match pattern="**.xls"/>
>>   <generate type="xls"/>
>>   <transform type="xsl" src="foo.xsl"/>
>>   <serialize type="xml" dest="context://repository/{1}.xml"/>
>> </match>
> I see two things here:
> 1) the current pipeline components don't seem to be asymmetric (and this 
> goes somewhat against what you wrote at the beginning of your email), 
> the asymmetry is in the fact that the serializer output is *always* 
> bound to the client response. Am I right on this assumption?

The fact is that the request is (down-to-earth) a URI, and a response is 
a stream. This is not symmetry.

> 2) what is this pipeline returning to the requesting client? This is not 
> SMTP, we have to return something. Sure, we might simply return an HTTP 
> header with some error code depending on the result of the 
> serialization, but then people will ask how to control that part.


>> Several of the existing
>> generators would be highly usable in input pipelines if they were
>> modified in such a way that they read from "standard input" when no
>> src attribute is given.
> I lost you here.

My take: If you use a Generator with a source protocol, it's more 
flexible. Add a protocol that gets data from request input, and you're done.


> Wouldn't the following pipeline achieve the same functionality you want 
> without requiring changes to the architecture?
>  <match pattern="myservice">
>   <generate type="payload"/>
>   <transform type="validator">
>     <parameter name="scheme" value="myInputFormat.scm"/>
>   </transform>
>   <select type="pipeline-state">
>    <when test="valid">
>     <transform type="xsl" src="myInputFormat2MyStorageFormat.xsl"/>
>     <transform type="my-business-logic"/>
>     <serialize type="xml"/>
>    </when>
>    <otherwise>
>     <!-- produce an error document -->
>    </otherwise>
>   </select>
>  </match>

I basically asked the same thing... but we cannot have a generic payload 
generator yet.


>> The ability to handle structured input (e.g. xml) in a convenient way,
>> will probably be an important requirement on webapp frameworks in the
>> near future.
> Agreed.
>> By removing the asymmetry between generators and serializers, by letting
>> the input of a generator be set by the context and the output of a
>> serializer be set from the sitemap, Cocoon could IMO be as good in
>> handling input as it is today in producing output.
> I don't understand what you mean by 'setting the input by the context'.
> As far as allowing the serializer to have a destination semantic in the 
> sitemap, I'd be against it because I see it more harmful than useful.
> I do agree that serializers should not be connected only to the servlet 
> output stream, but this is not a concern of the pipeline itself, but of 
> who assembles the pipeline... and, IMO, the flow logic is what is 
> closest to that that we have today.
>> This would also make it possible to introduce a writable as well as
>> readable Cocoon pseudo protocol, that would be a good way to export
>> functionality from blocks.
> I agree that a writeable cocoon: protocol is required, expecially for 
> blocks, but this doesn't mean we have to change the sitemap semantics 
> for that.
>> There are of course many open questions, e.g. how to implement those
>> ideas without introducing to much back incompability.
> The best idea is to avoid changing what it doesn't require changes and 
> work to minimize architectural changes from that point on.

Yup, exactly.

> But enough for now.
> And thanks for keeping up with the input-oriented discussions :-)


Nicola Ken Barozzi         
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)

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

View raw message