cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uli Mayring <u...@denic.de>
Subject Re: Jo! & WAR file apps
Date Mon, 05 Nov 2001 00:02:54 GMT
On Sat, 3 Nov 2001, Stefano Mazzocchi wrote:

> [sorry for crossposting, but this interests both communities, I think]

I believe so, too, so I maintained the crossposting.

> One question: you want to remove the connection overhead in order to
> obtain Cocoon services and I agree that this is a "good thing"(tm).

Not only the connection overhead, but also the Sitemap overhead, the
Cocoon pipelining overhead etc. - it's not only a question of speed, but 
also one of usability.

> Originally, Pier and I designed Cocoon2 to be an avalon block but
> decided to move away from that since the APIs weren't solid enough.

Fair enough.

> Now, this said, please reread the above sentence: the key part is
> "obtain cocoon services".
> 
> Cocoon is, like it or not, based on a request/response paradigm that is
> modelled after HTTP.

What is the philosophy behind that model? Why tie Cocoon to a specific
delivery method, even though only philosophically? Shouldn't there be a
more generic API with HTTP-like request/response being just one of several
wrappers?

> So, my vision is that if you want "XML --> XSL(T|FO)" processing block,
> you are going to create a behavioral interface that doesn't ask for a
> particular Cocoon resource, but pushes the various streams into the
> service and wants to obtain a result.

Yes, I am very open as to the exact API, but I think it should be simpler
than having to install a whole Cocoon pipeline and push my request over
HTTP. It is probably not very hard to write an Avalon block that does
XML-->XSL(T|FO) - I think most of the code can actually be stolen from
Cocoon and we just need some Avalon wrappers. So I can do that by myself
if the Cocoon project thinks it's a bad idea.

> I simply do not and for the reason above: IoC means that you ask for a
> resource to Cocoon and it knows what to do.
>
> This is a design pattern that must not be altered in any way, under any
> circumstance or Cocoon will be nothing different from
> Xerces+Xalan+FOP+Batik.

You call it a design pattern, but 10 years ago such a system was called a
monolithic black-box. Of course every system is a monolithic black-box at
some point, if you go deep enough. But then every system is also IoC and
it is arbitrary where you define the legal entry-points to be.

I think "Xerces+Xalan+FOP+Batik" is not Cocoon. These are seperate
projects and every Apache project can use them as they see fit. But I
think it would be good, if the various projects could agree on interfaces. 
But this interface cannot be Cocoon, because it assumes too much. For me
Cocoon is the Sitemap, XSP, generators, serializers etc. - of those I
would only like to steal XSP, because code generation may be useful in
other places as well.

> I hope you guys understand my strong feelings about IoC.

Is there any "mission statement" or white paper that explains exactly what
IoC is and why Cocoon uses it? Perhaps I misunderstood it, but to me it
looks like some arbitrarily defined interfaces and everything below is a
black box.

> If not so, please, make yourself heard because it's vital that we all
> agree on something so basic.

If I remember correctly, in the ca. 2 years I've been involved with Cocoon
and recently Avalon I haven't managed to persuade anyone of anything.
Actually, much of what I said one year ago wouldn't persuade me today,
either. So, chances are I'm in the minority again with my opinion :)

cheers,

Ulrich

-- 
Ulrich Mayring
DENIC eG, Softwareentwicklung


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message