Re: [RT] Input Pipelines (long)

[Nicola Ken Barozzi]

(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 :-)

Indeed.


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


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]