Stefano Mazzocchi wrote:
IMHO it's useful, but it still needs a bit of work for the new environments that will be done now.Nicola Ken Barozzi wrote:Good question.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?
Many people that don't like Cocoon told me so. I'm still debating in between myself since we came out with that concept two years ago. I still haven't decided.
We have been using it just to make a CLI that users seems to hate because it's slow
*some* users.
Yes, some.
Yeah, but *if* they found out how to do it (not everyone did easily, if ever), they had to change the code that got that, because originally they just got the Request, that after was not the right object...while making angry many developers that had to change all the objects the has HttpXXX servlet APIs hardcoded to use our abstraction.No, I don't buy that. The reason why we provided a way to obtain the original Servlet request was exactly to avoid them having to do it.
Yup, but it was deemed as a minor hack just to get a specific feature be used. But now it's not so specific, since getting the inputstream from the Request is not only from servlets. I don't want this hack that was used specifically for one case leak in the general abstraction definition and be used as a normal worksforme.Nicola, just because you didn't know the dependency was there it doesn't mean that it's *leaking* in. It has been that way since the day we created the environment.And now, we should let the dependency leak in again?
Looks hacky? well, yes and no. When the JDK introduced Java2D they came out with a new Graphic2D object but the paint() method passed a Graphic object. So it's up to you to up-cast it.
void paint(Graphic g) {
Graphic2D g2d = (Graphic2D) g;
...
}
It's terrible, I know. It hurts my elegance feeling like nuts.
So it does our abstracted Environment.... but the Servlet API are not abstracted enough and the abstraction job is a stinking hard one! expecially if you have to provide back-compatibility.
I'm all in favor of adding input capabilities to the environment, but only after a sound and well-thoughtout discussion.
I agree. That's why I was discussing with Vadim, and now with you :-)
If we really want an evvironment, we should make it as generic as *reasonably* possible.
I agree.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.
Look, I agree. I just don't want to add things to such a critical contract without *extremely* careful thinking.
Same here.
Yup. In Morphos I abstracted it by using "Object", but it's really a leaky abstraction generally speaking.Aha, here you say it too. Environment = Request + ServletRequest
Oh, yes. I've always known that Request didn't have a way to get input... but people stated that it was *impossible* to do so and this is where I got nervous.
So Cocoon is instrincially asymetric unless we are in a servlet environment?
Today? yes.
Must it be so? no.
Is it easy to abstract the input out of any possible client/server architecture environment? god no!
Is it true that all client/server architectures are symmetric? NO!!!Why *servlet* and not *web*? Shall we decide that all symmetric environments give a ServletRequest? Is the ServletRequest then part of the contract?No, I much rather see input abstracted in our Environment. I'm just concerned about careful thinking.
[...]
I disagree. The above text is correct only if the source gives you xml data, which is not necessarily the case.The fact is that Generators should not care where the source comes from, just take an object and transform it to xml.
If that was the case, we shouldn't need plaggable generators, but just different sources and one parsing generator. But we would be back to the same thing, just with different names and sitemap semantics.
A source can give be a stream, that can contain xml, html, pdf, doc, whatever, and all of these need different generators.
By mixing the locator phase with the generator phase, we loose easy to get flexibility.Careful here: I agree that the difference between a source and generator is subdle, expecially since we added a method for a source to generate sax events directly.
But I find the concept of 'locating' a resource is very weak in our current sitemap context.
I don't understand what you mean here.
Errr, the 'more than evident'-ness came from creating Morphos, not from the above snippet.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.
I don't this this 'more than evident'-ness.
Let me try to explain.
When I want to generate a SAX event stream, I have to do two things:
1) get the stuff
2) transform the stuff to xml
For example, if I want to do it with an XML parser, I can do:
//what to get
String urlString = "...";
//get it
URL location = new URL(urlString);
//parse it
xmlparser.parse(location);
Imagine that I want the parser to parse from a xmldb.
I just need to be able to make the URL open the correct stream, and give it to him.
The URL is not *the* data, but a *handle* to the data.
The string, instead, is nothing. Just a string.
The URL, the "locator", is what takes the string and is able to get the stream that that string points to.
The Parser, just take a URL and generates SAX events from the stuff that the URL (locator) gets for him.
> What does your above locator do? what is the difference between
> that and a Reader?
Good question. Not much, other than the fact that a locator should only get the source, while a reader can be made to be a stream "transformer".
It's quite easy, if we want, to make multiple readers in a pipeline, and that would be really different from a locator.
Anyway the sources are good enough, no real need for a "locator", I just put it there to try and explain the separation from locating a resource and generating SAX events from it.
The cocoon protocol is roughly the equivalent of the locator.Maybe I'm dumb, but I don't get this.
Errr I meant the Cocoon Sources, sorry.
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.That's great. We were waiting for people to be willing to use cocoon in their mail system before attacking the SMTP part of the Environment abstraction.
And *that* will require careful thinking about input, since that's where SMTP is focused on. Unlike HTTP that is focused on output.
Yup.
Listen, my needs came from real use-cases, not symmetry-driven architectural design. I just happened to chime in this thread because part of what was discussed here matched with my needs.Let's not talk about using it as a bean! How can I simply give cocoon a stream to process!I'm in favor of a discussion about abstracting the Environment futher to be more input-friendly also for mail environments, but this must come out of a deep discussion *and* after some *real-life* requirements.
What I'm opposed to is symmetry-driven architectural design.
It's irrelevant anyway. Even if they were, who cares, as long as it works well.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.
Correct. Summarizing this thread a little: 1) I don't think Cocoon pipelines are asymetric.
2) I agree that the Environment is asymettric.(*)
3) I would like to see an effort to make Environment more symmetric in respect of input
Actually, the input pipelines discussion, as I understood it, is simply about the possibility of executing two pipelines per request, with the flow in the middle.
Cocoon2 is something that gets data from a Request, mainly the URL and some params, and generates a response with some xml stuff.
In web services though, the "Request", needs to be actually created from an xml stream coming in.
Hence the talk about input pipelines, that would be those pipelines that work on the request stream to generate the request that would drive the normal Cocoon process.
By separating the processing in two steps, it has been shown how we fulfill the need that is needed for selecting based on pipeline content by not doing it: first we process the xml with an input pipeline, create an intermediate "Request", and then select based on that data.
This two stepped process made Cocoon seem asymmetric because now it cannot explicitly do it, and this two step thing seems more symmetric, etc etc etc.
4) I would like to see Environment abstract enough to work in a Mailet environmentOk, wait for a new thread on this. Let's keep this thread for the real input pipeline discussion. (*)
5) I would like this effort to be driven by real-life needs rather than purity and symmetry-driven architectural design (since we've seen that it often leads to very bad mistakes!)
--
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]
