Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3BE704C9.BDD5D44A@apache.org>
Date: Mon, 05 Nov 2001 22:29:45 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: Avalon Developers List <avalon-dev@jakarta.apache.org>
CC: cocoon-dev@xml.apache.org
Subject: Re: Jo! & WAR file apps
References: <Pine.GSO.4.10.10111050021001.362-100000@denics7.denic.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Uli Mayring wrote:

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

Hmmm, ok, let's factor this out.

Let's take Cocoon 2.0. Let's remove the "connection overhead", then the
"sitemap overhead", than the "cocoon pipelining overhead".

What the hell do you end up having?

We *are* already moving a bunch of components over to avalon-land, those
components that could be useful for many other stuff and not only
cocoon's.

You what to remove the Servlet API interface, than the sitemap, than the
pipeline. So, what you want to do: assemble the pipeline components by
hands and run them? should this be called Cocoon?
 
> > 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?

The philosophy is that this is what I needed when I started the project
and then found thousands of people that had the same need and joined the
ride (you as well).

> Why tie Cocoon to a specific
> delivery method, even though only philosophically?

Cocoon is not bound to any delivery method. It's bound to the a very
general request/response mechanism and even has an pluggable enviornment
and object model that was abstracted over HTTP.

> Shouldn't there be a
> more generic API with HTTP-like request/response being just one of several
> wrappers?

for example?

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

Read my lips: if you want to remove the connection overhead from Cocoon
and write an avalon block around it, I'm fine with that, as long as the
main architecture is not compromised by that.

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

What I don't understand is what you want to achieve that some 20 lines
of glue code around JAXP 1.1 wouldn't already achieve.

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

Wow. What a sentence :)

> 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 agree with this statement.
 
> 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.

Oh, I think nobody in the java world disagree with you on this.

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

As I said, we are happy to factor out all components that can be useful
someplace else, including code generation.
 
> > 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?

what the heck is a "mission statement" on a open source project?

> Perhaps I misunderstood it, but to me it
> looks like some arbitrarily defined interfaces and everything below is a
> black box.

If this is your vision, there is very little I can do about it.

You'd like to use some of the internal Cocoon functionality in a
procedural way (you call the API), while Cocoon is a declarative
framework (it calls your code to do stuff).

Those are opposite directions and cannot work together.
 
> > 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.

This doesn't mean 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 :)

Ulrich,

I don't have anything against your proposal if this requires to move
some Cocoon functionality over to Avalon. Both projects already agreed
that this is a good thing to do.

But, please, understand that if you want to take Cocoon and cut it in
pieces just because you need part of it for your own stuff, well, do it,
but don't call it Cocoon because it would not be anymore.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


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