cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <di...@webweaving.org>
Subject Re: cocoon2 & webserver ponderings
Date Sat, 15 Apr 2000 07:45:30 GMT

On Fri, 14 Apr 2000, Stefano Mazzocchi wrote:
..
> Anyway, while we speak, the Apache newhttpd group is working at
> designing the architecure for Apache 2.1, which is supposed to implement
> (finally!) layered I/O. This means that you can post-process the output
> of one apache module with another one. Unfortunately, they have no
> notion of SAX events so the whole problem of servlet chaining is back
> again.

This is a common misunderstanding caused by to much abstraction
desires. When you go down to the protocol layer at some point you need to
get specific. And define what SAX event maps to what. Or how the protocol
and it's identifier space maps onto your virtual world.

I see little or no problem of writing a chain which is Sax aware. Whilst
still relying by and large on the core apache code to implement the
protocol correctly and do all the low level system/scaling stuff right. 

In fact I think that the current handler infrastructure (which I
disly; I've always prefered vector arrays since the times of the BBC
Micro) is much more suitable that the 1.3 tree. For a commercial project
we are looking at some of this to do WML more efficient; and found that
2.x is more managable.

> architecture... many new-httpd people simply don't have enough XML
> experience to understand those issues right away, of, if they do (Dirk,
> Ben) they are not directly involved in any coding.

Wrong I fear :-).  And the architecture shaping up right now is remarkably
(and intentionally) quite inspecific. Which means it will work well. A lot
of people there really understand what backend's, of which XML is just
one, need to scale, be maintainable and so on. No worries there. As long
as it is a clear thin layer which just gets a RQ mapped into a space.

This does mean however that when you want to bring it up to the XML world
(or the coldfusion world, or any other programming space) you will need
glue code which to some extend understands http, your take on URI coding
and mapping of your space and quite possible, depending of how you
architect, some rudimentary knowledge of HTML/WML/... their 'form's and
how the key/value pairs map to what you get back in the protocol layer;
i.e. the GET/POST information.

But that is what you get when you use HTTP. 5 years back much the same
arguments where used on CORBA lists arguing for a dynamic dispacher
engine. IDL was the compromise. SNMP mib compilers do this as well for the
get-next. Is goes for virtually any protocol where you allow interaction
in sequences beyond an atomic protocol transaction.

Dw


Mime
View raw message