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.
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.
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.
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.Look, I agree. I just don't want to add things to such a critical contract without *extremely* careful thinking.
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.
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.Aha, here you say it too. Environment = Request + ServletRequest
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.
Yes, something does: usability coherence. you can't make a protocol available everywhere and another available only in some spots.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.
This is not an argument.
But you still cannot prevent people from shooting themselves in the foot, and useOh, totally. I can't prevent people from doing something I consider a mistake, but I can avoid making it *easy* for them to do it.
<map:generate type="payload"/>
<map:serialize/>
and then calling it here
<map:generate src="blah.xml"/>
<map:transform src="cocoon:/givemetheinput">
<map:serialize/>
This is what designing a framework is all about: it's not the "there is always more than one way of doing it" FS-inflated paradigm, it's the "this is the way we consider best, if you don't like it, use something else or convince us of a better alternative".
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.
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.
In fact, I would not see as bad this:I don't this this 'more than evident'-ness.
<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.
What does your above locator do? what is the difference between that an a Reader?
The cocoon protocol is roughly the equivalent of the locator.
Maybe I'm dumb, but I don't get this.
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.
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.
Correct.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.
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
4) I would like to see Environment abstract enough to work in a Mailet environment
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!)
--
Stefano Mazzocchi <[EMAIL PROTECTED]>
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
