Stefano Mazzocchi wrote:
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.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.
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 abstraction.
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.
[...]
Aha, here you say it too.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)
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?
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 useHmmm, 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.
[...]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.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.
<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
<map:generate type="payload"/>
<map:serialize/>
and then calling it here
<map:generate src="blah.xml"/>
<map:transform src="cocoon:/givemetheinput">
<map:serialize/>
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">
<map:serialize/>
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.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.
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.
You say that not all evnironments have the need of it, and it's true, but a *class* of environments do.
--
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]
