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 Sun, 29 Dec 2002 23:12:35 GMT

Stefano Mazzocchi wrote:
> Nicola Ken Barozzi wrote:
>>> 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?
> Good question.
> 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.

IMHO it's useful, but it still needs a bit of work for the new 
environments that will be done now.

>> We have been using it just to make a CLI that users seems to hate 
>> because it's slow
> *some* users.

Yes, some.

>> 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.

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...

>> And now, we should let the dependency leak in again?
> 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.

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.

> 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.

>> 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!

Yup. In Morphos I abstracted it by using "Object", but it's really a 
leaky abstraction generally speaking.

> 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.


>> 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.

I disagree. The above text is correct only if the source gives you xml 
data, which is not necessarily the case.

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.

>> 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.

Errr, the 'more than evident'-ness came from creating Morphos, not from 
the above snippet.

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

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.


>> 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.

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.

>>> 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.
> Correct.
> Summarizing this thread a little:
>  1) I don't think Cocoon pipelines are asymetric.

It's irrelevant anyway. Even if they were, who cares, as long as it 
works well.

>  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 
> 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!)

Ok, wait for a new thread on this. Let's keep this thread for the real 
input pipeline discussion. (*)

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

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

View raw message