forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [OT] Re: Sitemap woes and semantic linking
Date Fri, 13 Dec 2002 08:07:50 GMT
Jeff Turner wrote:
> 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.

Yeah, well, that's highly debetable, but it's pointless to do so.

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

I don't know enough of AxKit to comment on this.

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

I like the fact that I can write my selectors/matchers in a pluggable way.

Should I throw that ability away for use mod_rewrite? forget it, dude!

Should I write a new apache module for every matcher and selector? and 
then, what about flowscript? and what if my reader is not just a blatant 
bit-2-bit copier but performs things like image rescaling and maybe has 
to cooperate with the flow? should I write another module?

Sure, if we had mod_java, then we could do that, but thinks like 
flowscript? forget it.

the HTTPd conf file has not enough semantics to be able to drive cocoon 
at its full power.

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

No, you misunderstood: it's the idea of having HTTPd using a conf file 
written using the cocoon sitemap markup and using modules as components.

But this is *wild* and too many things have to change inside HTTPd to 
make this possible.

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

My idea is different: let's remove the unnecessary Servlet API layer and 
let's glue cocoon directly to httpd's butt. This is what Pier and I have 
been thinking about in the last year or so.... since next year I'll 
probably end up living with him, expect something to happen.

NOTE: I'm not *mandating* this behavior to Cocoon. Just creating another 
wrapper: CLI, Servlet API and Apache API.

Last time that Federico Pierpaolo and I lived together, Avalon, James 
and Cocoon were born. I'm curious to see what will happen now :)

>>>*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 :)

We both still are. :) But we'd rather stay away from it.

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

No, you just misunderstood me there.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------



Mime
View raw message