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 Wed, 25 Dec 2002 10:45:26 GMT

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>> (my comments, based on the discussions that are going on lately and my 
>> work on the blocks move and doc writing)
> cool. thanks for sharing.
>> 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.
> Right. But the above sentence remains wrong, maybe Cocoon Request object 
> doesn't have a a method to get input which is abstrated from the 
> context, but it's *wrong* to say that there is no way to get input from 
> the user.

Being pricky, but "There is no method to get the input." is correct in 
the sense that there is no class method to get the input.

> The fact that the Request object doesnt' contain input is because we 
> couldn't agree on what *input* meant in a context-abstracted situation.
> So, as Vadim, I agree that we should get it in only *after* we know what 
> context-abstracted input means.

Yup, Vadim has easily convinced me too :-)

>> 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.
> There are two ways of implementing an API:
>  1) forcing common ground: that is creating a sufficiently abstracted 
> way to look at the problem
>  2) leaving context-specific hooks: the component connects to the 
> context-specific hooks.
> Java has a known history of using patter #1, but recently this has been 
> challenged very seriuosly (see Eclipse SWT vs. Swing) and with some 
> *great* achievements.

Ok, then let's ditch the environment alltogether 8->

> This said, do we really want to abstract our Environment objects so that 
> they are capable of handling all web, CLI and mail environments? Isn't 
> this FS?

Is the Environment itself FS?
We have been using it just to make a CLI that users seems to hate 
because it's slow, while making angry many developers that had to change 
all the objects the has HttpXXX servlet APIs hardcoded to use our 
And now, we should let the dependency leak in again?

If we really want an evvironment, we should make it as generic as 
*reasonably* possible.

Now the HTTPServlet  request has a getInputStream. We don't.
The day we will make Cocoon work directly in Avalon, we will break every 
Cocoon app using it, unless the Avalon container implements the same 
HTTPServlet  classes... which simply makes out environment abstraction 
unnecessary, since the HTTPServlet classes become the used abstraction.

> I'm not stating, just asking.


>> The fact is that the request is (down-to-earth) a URI, and a response 
>> is a stream. This is not symmetry.
> ??? what about those PUT WebDAV requests that might have a 10Mb payload 
> and return a simple two line http response with an error code?
> lack of simmetry is perceived because of the way the wep currently works 
> that is 90% of the HTTP requests are problably GET, 9.99% POST and 0.01% 
> all the other HTTP actions.
> But there is *nothing* instrincially asymetric in the web nor in how 
> cocoon pipelines work (if you consider your Environment as Request + 
> ServletRequest)

Aha, here you say it too.

   Environment = Request + ServletRequest

So Cocoon is instrincially asymetric unless we are in a servlet 
environment? Why *servlet* and not *web*? Shall we decide that all 
symmetric environments give a ServletRequest? Is the ServletRequest then 
part of the contract?

>>> 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.
> Hmmm, between
>  <map:generate type="file" src="input:web:/"/>
> and
>  <map:generate type="payload"/>
> I would choose the second.
> A full URI scheme for simply getting an input stream is too much and it 
> might be *very* dangerous since people will very easily abuse it like this
>  <map:generate src="blah.xml"/>
>  <map:transform src="input:web:/">
> which might lead to *serious* security concerns and cross-site scripting 
> problems with injected XSLT

Nobody prevents us from making it usable only from generators. And BTW, 
what you call a *serious* security concern is in fact something that has 
been asked for. But you still cannot prevent people from shooting 
themselves in the foot, and use

    <map:generate type="payload"/>

and then calling it here

   <map:generate src="blah.xml"/>
   <map:transform src="cocoon:/givemetheinput">

The fact is that Generators should not care where the source comes from, 
just take an object and transform it to xml.
By mixing the locator phase with the generator phase, we loose easy to 
get flexibility.

In fact, I would not see as bad this:

   <map:locate src="blah.xml"/>
   <map:generate type="xml"/>
   <map:transform src="cocoon:/givemetheinput">

This has come out of the Morphos effort, where it has been more than 
evident that locating a resource and injecting it into the pipeline are 
different concerns.

The cocoon protocol is roughly the equivalent of the locator.

>> [...]
>>> 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.
> Who said we should? Is there a *real* (non theory-driven) need for such 
> a thing?

> I've been using the request generator with good satisfaction even for 
> web services-like stuff and I don't need to send any input from the 
> command line (do you?) and a Mailet wrapper for Cocoon is yet to be seen.

The mailet wrapper is something I'm writing now, since I'm using james 
in my intranet, and I see the pain of not having it easy to make a 
Cocoon mailet.
Let's not talk about using it as a bean! How can I simply give cocoon a 
stream to process!

> Interface Elegance driven design is one step too close to FS from where 
> I stand.
> But if there are *real* needs (means stuff that can't be done nicely 
> today with what we have), I'm more than welcome to discuss how to move 
> forward.

As I said, moving from a servlet container to a non-servlet web 
container would break things, unless we have it implement the 
httpservlet methods.

You say that not all evnironments have the need of it, and it's true, 
but a *class* of environments do.

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

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

View raw message