cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Cocoon Architecture [was Re: [Moving on] SAX vs. DOM part II]
Date Mon, 24 Jan 2000 21:17:02 GMT
[changed the subject and removed the listed people since this is another

Niclas Hedhman wrote:
> Stefano Mazzocchi wrote:
> > Ok, but what is this discussion about?
> Exactly!!  The biggest 'problem' with Cocoon is that its purpose is not
> exactly specified.

All right. No matter how hard to specifiy the limits of a particular
discussion there will always be somebody that breaks them... :) oh

The very first line of the documentation says:

 "Cocoon is a 100% pure Java publishing framework that relies 
  on new W3C technologies (such as DOM, XML, and XSL) to provide 
  web content."

I read:

1) it's java based
2) it's web focused
3) it's publishing oriented
4) it works with new technologies

I think there is no problem in specifying what the purpose of this
project is. Problems arise when it doesn't cover your purposes :) but
that's a totally different story, don't you think?

> When the purpose is defined, we need to list the pro's and con's of each
> task/subpurpose, and how this can be achieved. There will also be needed a
> "expansion plan" on how to extend the underlying architecture (not talking
> about more producers and all that) without comprimising compatbility. Up
> until now, this has not been taken very seriously, but as more producers
> and formatters enters, the overall cost of re-writes staggers.

Hmmm, considering this project is my college thesis and will be probably
be my job for the next who knows how many years.... I personally don't
think I've not taken into serious consideration the architecture of this

Rather the contrary: it may not cover all possible aspects and may have
holes and things to improve... I've never said the opposite... but lack
of seriousness.... well, no, I don't buy that.
> Cocoon is said to be a Web Publishing Framework, but it COULD be a lot more
> than that. I strongly feel that it will ONLY be that, cause the major force
> of Cocoon (read Stefano) is so much into just that. 

Well, I proposed a project to do web publishing using the XML model and
I'm continuing in that direction since this is my current itch. It
strangely appears to be a good idea and a useful software, not only for

I'm currently focused on finishing what I started before covering new
grounds, but I honestly don't know how this will end up. One day any of
you could take my seat on this project, when I'll get tired of it.

> The requirements in
> other areas are side-stepped either because of performance concerns,
> implementation laziness or ignorance to the issues involved. (This is the
> reason why I have laid back in the Cocoon dev for the last 6 months.)

Uh, this tone is the perfect one to get flamed for in other mail
lists.... On one thing you're right: I'm lazy.

> I am just one representative of an "alternative market".  Our needs are not
> much of high volume, nor large document, static serving. We are in need of
> flexibility, dynamic creation, and most importantly;  requests and
> responses are not only HTTP, but also Email.  The SAD thing is that Cocoon
> is so close to what we need, yet too far away in many respects so that our
> alternative to hardwire our needs is more convinient than adopting Cocoon.

Niclas, we already had this discussion and the terms didn't change that
much: I'm all in favor of creating a wider and more useful architecture,
but I don't have that itch to scratch and you seem the only one who

Your requestor/responsor proposal was a good one, but it would transform
Cocoon into a servlet engine and this is not the right thing for this
project at this moment.

If we make Cocoon a servlet engine, or even worse, a web server or email
server, we loose the juice of it. I do believe in code reuse and
frameworks because they allow us to focus on what we need.

Cocoon is currently a servlet because this is the best way to be
portable without writing tons of code. True, this is a compromise, but a
good one since we are allowed to propose changes to the Servlet API
(I'll be an invited expert for the next round of the Servlet API

So, covering new ground must not reduce the ground already covered. This
includes porting Cocoon in other languages (a PERL port of Cocoon was
recently proposed to me), or even going native inside Apache (something
we discussed with the PIA guys).

Of course, Cocoon's power are the design patterns not the
implementation. On the other hand, those patterns are rather new and we
need better field knowledge to go forward and this takes time and
skills. Skills I admittedly do not have in many fields.

On the other hand, I think Cocoon was very successful in providing
useful technologies for real needs. This will not stop today, that's for

> And I think many are in the same position.

I think you are right in seeing powerful design patterns in Cocoon that
could be applied to other realms. But one thing is to reuse patterns,
another thing is to reuse software.

I placed a significant amount of work into the Cocoon architecture and
in prototyping some design patterns for response production on a servlet
based architecture.

Like Pier noted, us two where the first one to propose an extention to
the Servlet API that worked for other request/response protocols as
well. This work is being currently implemented in the JAMES project by
Federico Barbieri, who is going to be hired by Exoffice later next
months to work on Avalon and JAMES and integration with other Apache and
Exolab software.

Also note that Pier and Ricardo and Assaf and Keith are working for

And given that Ismael (Exoffice CEO) uses nothing but Cocoon, you
clearly see a strong requirement for integration with other tecnologies,
email up front.

> I still strongly believe in the
> Request -> Production -> Content Alignment -> Presentation Alignment
> -> Presentation Formatting ->  Response
> Request:  The incoming request from any of many different kind of sources.
>     Servlet
>     Command line
>     Email
>     Custom
> Production:  The generation of the RAW content, not necessarily suitable
> for presentation.
>     File
>     XSP generated
>     JDBC
>     Custom
> Content Alignment:  The filtering, sorting and other re-arrangments of
> content prior to delivery to the Presentation context.
>     XSLT (multiple stage, often none)
>     XSP generated XSLT (?)
>     Custom
> Presentation Alignment: Re-arrangment of Content to be more suitable for
> the Presentation at hand.
>     XSLT (multiple stage, often none)
>     XSP generated XSLT (?)
>     Custom
> Presentation Formatting:  Application of Style to the Content.
>     XSL FO
>     XSLT to HTML
>     XSLT to CSS
>     Browser formatting with external XSL FO or XSLT
>     FOP
>     Text
>     WML
>     Custom
> Responsors
>     HTTP
>     EMail
>     File / StdOut
>     Custom

What you outline is something like this

 requestor -> cocoon engine -> responsor

Now, if you look into Cocoon 1.6, this is _exactly_ like Cocoon is
implemented. But only three requestors are available

1) servlet 
2) command line
3) custom (used for Turbine integration and inter-java call)

I'll be ready to add "4) email" when Federico comes up with JAMES 1.0
and full MailServlet support. I assume this will take another month or

Note that this needs you to create your own HttpServletRequest/Response,
which is something dirty and I don't like it myself, but a custom
Request/Response object was just too similar for what we need. But, as
always, I'm wide open to suggestions on how to improve this. 

> The key to this model is that the interfaces between each stage must be
> abstracted, yet contain the HTTP headers and parameters, EMail headers and
> command-line parameters, and other future request type information. As well
> as context based information.

Yes, this is why I started abstracting the Request/Respose objects
and... miserably fail. :( The Servlet API is not multi-prototol but it's
heavily http based, even in its general form. Creating a new truly
multi-protocol servlet API is a scary task for me and I don't have the
time/energy/need to do that at this moment. (but I never stopped others
for doing it!)

> My only solution to this is an XML fragment generated by the Requestor, and
> passed on to each stage, and possibly both modfied and expanded. For
> instance, I think it would be a good idea to let the components record
> their activities into such a fragment in debug mode, and a formatter and
> responsor is used to send the debugging result somewhere.

I don't like this, not only for performance reasons: good OOP requires
abstractions in OO code to be designed as objects, not DTDs. You should
access your request data thru methods, not XPath queries. You gain
nothing using XML on this stage, plus, designing a DTD is not easier
than designing an API.

My performance concerns are still there, but I would throw them away if
you could prove the absolute need for such a thing against an API-like
design. On the other hand, talking as a component writer, an API would
be much more easy to learn and use. This is, in fact, the exact same
pattern used in the creation of the Servlet API for http: instead of
parsing the http headers and do all that directly, provide some good
methods to hide all the protocol details.

Unfortunately, they failed to provide a true protocol-abstracted API and
Cocoon suffers from this. :( I'm totally aware of that.
> I would also like to point out, that when XSLT is used for generating
> well-formed HTML or creating FOs,  it is a formatter, belong to the
> Presentation layer and not the Content Layer. And this is important from an
> educational point of view. I.e  document transformation is BOTH a Content
> context, for filtering, sorting and other content based re-arrangements,
> and a Presentation context, for formatting. That is hardly ever
> distinguished in the discussion.

Good point. I'll be more than happy to accept documentation for the
Cocoon project that explains your points better or suggestions on how to
improve the docs based on your ideas. Niclas, I'm sorry you feel left
out of the fun around here, and I apologize in advance for anything that
I might have done to make you walk away from this project.

but I'm open to suggestions and ready to reconsider my decisions. But
remaining silent is not the best way to interact...
> Another thing I have noticed....  I find a lot easier to make small XSLT
> sheets that each do a single simple thing, than trying to incorporate all
> transformations in a single sheet. It also makes stylesheet re-use and
> establishment of XSL libraries easier. Therefor I have the multiple stage
> XSL transformations as a basic feature.

The Cocoon architecture is totally orthogonal to the number of
transformations involved. I do not have enough field knowledge to say
which one is the best.

> What are different people working with?
> I can see 5 kinds of people working on large projects;
> SiteManagement
>     Requestor
>     Responsor
>     GenerationPath (SiteMap)
> Content Logic
>     Producers
>     Transformation
> Presentation Logic
>     Transformation
>     Formatters
> Content
>     Static XML
>     XSP taglibs
>     Custom
> Presentation
>     Static XSL
>     XSP taglibs (?)
>     Custom

Good analisys.
> To me, this is a clean analysis of the needs/purpose (or potential purpose)
> of Cocoon, and I feel a satisfactory design can easily be achieved, that
> satisfies the needs of more people than the current proof of concept.

As far as I'm concerned, you'll always find me here listening for

And with the XSP implementation and many other fixes here and there, I
do not think Cocoon is a proof of concept anymore, but a real and useful
software. True, key issues like the sitemap need to be addressed, but
this is already planned and being worked on.
> As for the less important, but highly discussed, issue of DOM versus SAX.
> Wouldn't it be proper to have a DOMbuilder as a utility class, in such a
> way that whoever needs a DOM or DOM fragment, will listen to the SAX
> events, and when the start of the fragment is trapped, the SAXstream is
> "handed over" to the DOMbuilder, which will return with the DOM fragment at
> the closing tag, and the original SAX receiver continues listening. Call it
> DOMonDemand  :o)  I would think that satisfies just about everyone. It will
> also show better overall performance only to DOMize the part that a
> component is interested in, instead of the SAX2DOM streams/pipes that has
> been proposed earlier.

I'll reply to the real discussion part on another mail.

> Stefano, thanks for inviting to an open challenge of the current "proof of
> concept".

You're welcome. I'd love to do this once every three months or so, just
to see if new people coming in has better ideas or new features to

I do not think that walking away is the best way to make a project suite
your need, don't you agree with me? :)

> The one who can't refrain from speaking...
> Niclas Hedhman

Never thought this was a problem. On the contrary: keep it up! :)

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------

View raw message