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 23:43:15 GMT
On Mon, 5 Nov 2001, Stefano Mazzocchi wrote:

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

Cocoon would remain what it is, it might be distributed as a .sar
application instead of a .war application. The functionality would be 100%
the same - with the exception that some people (like me ;-) could do
*more* with Cocoon, e.g. use it in a world that is not made up of a
request/response pattern. I am not talking about Cocoon's functionality,
just its internal structure, so the product would remain the same.

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

No matter what we call it, but it would be more than Cocoon does now :)

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

Yeah, I didn't mean the Cocoon1 philosophy, that product has been
abandoned. I thought maybe this request/response pattern was re-thought
for Cocoon2 as were so many parts of Cocoon1.

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

Ok.

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

For example queue-based systems. Maybe some people would like to use a
JMQ-like system. Or rules-based systems. Maybe I'm getting carried away
here. Need more think :)

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

For my program it does not make a difference which way I do it. I just
thought that maybe there are several people out there and we all could
agree on a common format. This common format might become a factor, if
Cocoon used it as well. That's all.

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

Well, some kind of a text. A white paper, a design document, whatever you
like to call it.

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

Well, you could tell me why the interfaces are not arbitrary and why
everything below is not a black box :)

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

IIRC we had some very heated discussions about that in Cocoon1 times as
well. Constantly people would come and ask "how can I call Cocoon from my
servlet/EJB/whatever". And the response always was: "Convert your
servlet/EJB/whatever to an XSP taglib and let Cocoon call your
functionality." Apparently we're running into the same old problem here:
you can use Cocoon, but if you use it, you must commit to it. Throw your
other stuff away.

I love Cocoon. There are some things that can be done extremely well with
Cocoon. But in-between Cocoon1 and Cocoon2 I grew suspicious of that 
commitment. I still think the Sitemap is too proprietary a concept. I'm
not saying that to criticize Cocoon, just to explain where I'm coming
from in my thinking. Actually, I'm saying all that evil stuff in order to
help the Cocoon project :)

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

Destruction is not negative, you must destroy to build. Quick, who said
it? :)

Seriously, have a look at this fictitious history of a web application
developer (the timeline is very arbitrary):

1993: Wow, that WWW sure looks cool. I'll write some HTML pages right
away. My boss won't understand, but one day I'll be the star of the
company.

1994: Hmm... need something to convince the boss. Let me put that cute
page counter in. A small CGI/Perl script, no problem. Maybe I can hook up
the coffee machine.

1995: We sure have a lot of HTML pages and I can't get any work done,
because I'm constantly updating them. Whoever said the Web is for our
marketing department to publish their blurbs??? I need to write some kind
of generator that makes the HTML pages for me. Especially the navigation
bar, it's the same thing on every page anyway. Another Perl script, this
one a bit larger.

1996: Ok, the boss finally gets it. Now he wants all kinds of
functionality on the web pages. More Perl scripts. What do they mean with
"relaunch"? Oh my God, they're bringing in a designer, how am I going to
teach that guy Perl??

1997: A web shop?? Are you crazy??? This has got to stop. We need some
common platform for our web functionality and it must integrate with our
backend systems. Let's do Java on the backend and use servlets for the
frontend. SSI is good for including the navigation bar.

1998: That Java stuff sure is cool. But it sucks to have so many servlets
and each of them needs to write out HTML. We've put much of our HTML pages
into servlets. Where are my icons?? Chaos!

1999: Man, this Cocoon is the total package. I'll get my HTML transformed
into XML (which is way cool) and out of the servlets and back into the
filesystem, where it belongs. Plus I can call real Java code from the XML
pages, and what's more, I can wrap it in XML taglibs. Life is so good to
me.

2000: Ok... the Cocoon frontends are nice, but they do too much.. the XSP
pages don't really look like content, they look like logic in an XML
wrapper. I have to put much of that logic into the backend, where it
belongs and can be maintained independently from the frontend. My
colleagues don't know Cocoon, but they do know Java. And I have to finally
find a sensible platform for all our backend programs.

2001: Yeah, Avalon rocks, it can run all our backend programs as blocks.
Wish they would release the goddamn framework. But our backend is in great
shape, everyone can maintain it, we basically accept the Avalon wrappers
around our classes and just code away. Now it's time to look at the
frontend again. And what do you know? There's a whole new Cocoon out there
and it is built on top of Avalon. I'm in paradise - I'll just grab that
.sar application, throw it into the Phoenix apps directory and all our
backend blocks can instantly talk to Cocoon. Seamless integration of
frontend and backend - this is so good, I think I'm going to get drunk
right away.

Well... some parts of this story are more fictitious than others! ;-)

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