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.
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.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.
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.
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.
See above.
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.
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?
I'm not stating, just asking.
??? what about those PUT WebDAV requests that might have a 10Mb payload and return a simple two line http response with an error code?[...]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.
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)
Hmmm, between2) 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.
<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
Who said we should? Is there a *real* (non theory-driven) need for such a thing?[...]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.
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.
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.
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
