cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ulrich Mayring <>
Subject Re: Jo! & WAR file apps
Date Tue, 06 Nov 2001 18:32:12 GMT
Sylvain Wallez wrote:
> > In my mind it does not make sense for the daemon program to open a
> > to Cocoon. The PDF generator and the daemon are
> > both backend components and could both run very sensibly under Phoenix
> > and talk to each other using the well-defined Avalon contracts, instead
> > of stateless HTTP. I hope that example convinces you that the world is
> > not a one-way street, if not perhaps you have a better suggestion for
> > this concrete example. But please don't tell me to move the daemon's
> > functionality into the frontend :)
> The daemon program doesn't have to open a The
> Cocoon environment is abstracted and two implementations come with the
> distribution : servlet and command line. Just define your own as an
> Avalon service and you're done with what you need.

Well, this is exactly what I was looking for. I haven't found any docs
describing this procedure, that is why I asked on this list.

> It's true that Cocoon Environment was designed with request/response
> paradigm in mind and that it heavily mimics the servlet interface. But
> is a request/response really different from a method call on an
> interface ?

No, if the method is sufficiently abstract. If I have a method I can
pass a couple of Strings into and get a String back, then I can build
whatever I need. But I think this type of access should be standardized
and de-coupled in some way, so I like the first option better, where I
have to implement an interface (if I understood you correctly).

> And if that's not enough for you, Cocoon just an implementation of a
> "Processor" (see org.apache.cocoon.Processor) that builds a Pipeline
> according to a given Environment (http, commandline, whatever). That
> could be the service you're looking for.

Ok, so here's a third option. My question was if there is a standard way
to do it and the response was that I destroy IoC with that idea :)

> About this particular "too proprietary" statement you say often, let me
> say also that I really don't understand it. What do you mean by
> "proprietary" ?

It means that it is not a standard like, say, XML or XSLT or HTTP.

> Contribute ideas and/or code instead of criticisms and you will be
> heard.

What is the difference between an idea and a criticism? An idea means
"let's do it this way" and it implies the criticism "the way we do it
now is not good enough". Anyway, you're taking things to a personal
level, which I don't think is appropriate. It should not be about me or
you and what each of us has done for the project, we should discuss
things on a rational and technical level.

> If this means "not a standard", then this also true : this is not a
> standard from W3C, JDK, whatever. But does it need at all to be a
> standard ? Is Avalon you seem to love so much (I do also) a standard ?
> Not either. Most standards in the software industry emerge today from
> research projects or developper communities. Cocoon is both. Take SAX
> and javax.xml.transform : there are now a standards, but started as the
> work of developper communities.

Well, these are several points, I'll try to address them seperately, but
briefly. If you like to go into more detail, then ask me back:

Does the Sitemap need to be a standard? I think yes. It is THE interface
to userland and it is doing a lot of things. Everyone must decide for
himself, if he can afford to bet his company on this concept. It is very
hard to port a Sitemap-based application to another platform - but if
the boss tells me so I have to do it.

Is Avalon a standard? Nope, but it's much easier to port an application
from Avalon to another platform. Remove some wrappers and you're almost
done. Plus, Avalon is friendly to all kinds of integration.

Standards emerge from developer communities. This is true and I don't
think I have disputed that claim. Allow me some wild speculation on
this: do you believe the W3C would accept the Sitemap as a standard, if
it were written up correctly? I think they would want something more

> > Again: I don't want to call Cocoon from my programs. That is in fact
> > exactly what I want to avoid. All I want is to ask Cocoon to be nice and
> > not claim exclusive ownership of things like "XML==>XSLFO==>PDF". Cocoon
> > can (and does) claim exclusive ownership of the Sitemap, but it can't
> > (and doesn't) claim exclusive ownership of the URI space. In general:
> > control your invention, but not the inventions of others.
> Cocoon doesn't have any ownership of these : there is no XSL processor
> in Cocoon, but it integrates cleanly with Xalan, Saxon, or XT any other
> XML (not just XSL) transformer. It doesn't have a FO renderer but uses
> smoothly FOP, RenderX or JFor.

Didn't I just know this argument would come? :)

Cocoon uses smoothly FOP, Xalan, RenderX and many more, because these
tools have a well-defined interface for using them. Unfortunately many
of those tools have different interfaces (not considering JAXP and
friends for the moment). Instead of n software developers writing n
wrappers for these interfaces I suggested that the Cocoon project might
be a great place to provide standardized interfaces to the world.

Of course Cocoon doesn't claim ownership of these technologies in the
sense that I cannot use them without Cocoon. But Cocoon does claim
ownership of its interfaces to these technologies and I am kindly asking
to share these interfaces with others.

> What Cocoon does is provide means to assemble all these in pipelines to
> produce resources described by an environment. That's all, but that's
> done in a way that allows each concern not to overlap with others. If
> you want to have a static and hard-coded XML->XSL->FOP pipeline, just
> write down a few dozen lines of glue code and you're done. You don't
> need Cocoon for that.

I need Cocoon for the frontend anyway. Is it really such a strange idea
that I want to re-use what is already there in another context?


Ulrich Mayring
DENIC eG, Systementwicklung

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

View raw message