forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: [OT] Re: Sitemap woes and semantic linking
Date Fri, 13 Dec 2002 07:12:19 GMT
On Thu, Dec 12, 2002 at 07:36:24PM -0800, Stefano Mazzocchi wrote:
> Jeff Turner wrote:
> >On Thu, Dec 12, 2002 at 12:07:34PM +0000, Andrew Savory wrote:
> >
> >>On Thu, 12 Dec 2002, Jeff Turner wrote:
> >That's what I'm saying: the sitemap is great, but it should be the
> >"servlet container sitemap", not the "Cocoon sitemap".  There should be
> >URI management tools (notably URL rewriting) standardized right in
> >web.xml.
> Jeff, if you experienced *years* of fighting over the Servlet API Expert 
> Group to get exactly what you describe, maybe you wouldn't bash the 
> Cocoon Sitemap so much.

I was not bashing the Cocoon sitemap, nor the hard-working people who
made it a reality.  I'm saying that, in a better world, the web server
would do all the URI management, and Cocoon would be left with just the
job of transforming and rendering XML.

This 'better world' does not exist in Java-land, so I cannot criticise
the route Cocoon took.  But I think it _does_ exist in the non-Java
world, if you view Apache HTTPd as the webserver, and I _suspect_ (never
having used it) that this is how AxKit got away with not implementing a

> >Here is an analogy: why doesn't AxKit have a sitemap?  Because it doesn't
> >need it.  It relies on Apache httpd's native URL management ability.  All
> >AxKit needs are those few pipelines for defining XML transformations.
> Here, Jeff, you miss another few years of talks between myself, 
> Pierpaolo and the HTTPd 2.0 layered I/O architects, trying to estimate 
> the ability to have HTTPd 2.0 using something like a mod_cocoon and 
> referring back all processing that made sense to APR (thru a JNI interface).
> At that point, we *might* try to run Cocoon connected directly to the 
> Apache module API, thus bypassing all the servlet API limitations and 
> being able to handle back processing (like map:read, for example) to 
> where it belongs.

'Referring back'..
'back processing'..

I don't think you understood my point.  There should be no need for fancy
HTTPd <-> Cocoon interactions.  There should be strict IoC, with the
webserver, not Cocoon, in full control of the URI space, delegating small
portions of it to Cocoon. 

> NOTE: httpd 2.0 has a pluggable configuration facility. in the future, 
> we might be able to use the cocoon sitemap to drive *httpd* directly.

Cocoon telling httpd what to do.. isn't that classic subversion of

> Once again, please, don't underestimate the effort that is put in the 
> design of a complex software system. You're appear disrespectful and 
> this might bite you back later on.

As I said, I'm not criticizing _anything_ about the design of Cocoon or
the Cocoon sitemap.  I am lamenting what seems to be a fundamental
screw-up in the entire server-side Java processing stack; that the
webserver has such poor URI management facilities that tools like Cocoon
feel it necessary to take the job upon themselves.

I would _love_ to have a Cocoon-like sitemap in Tomcat.  Imagine.. the
URI space could be completely independent of the filesystem!  I could
store a whole website in a RDBMS and map it to the URI space.  IIRC,
Craig McClanahan said that they were considering a JNDI abstraction for
the filesystem (as Tomcat 4 does internally) in the servlet spec, but
sadly it didn't happen.

> >*shrug* There's no real solution now.  The only feasible 'URI daemon' is
> >Apache httpd.  More and more I agree with Pier Fumagalli, who had some
> >enlightening rants on tomcat-dev about the need to treat httpd as
> >_central_, and Tomcat as _only_ a servlet container.  Forget this idea
> >that httpd is optional.  Put it right in the centre, use it for URI
> >management and static resource handling, and delegate to Cocoon only the
> >things Cocoon is good at handling.
> Should I remind you that Pierpaolo is the guy that designed the Cocoon 
> sitemap with me?

I know.. back then he was a Tomcat committer too :)

> Believe me, we have spent so much thinking about ways to make httpd and 
> java talking closer together that I'm sick of it. But the political and 
> technological inertia is *not* something that should be underestimated. 
> And I mean on both sides of the fence: servlet *and* httpd!

Perhaps because you're trying to fix a _major_ architectural flaw by
breaking IoC between the webserver and Cocoon?


View raw message