cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [TIPS] Basic configurations of Apache 2.0 for Cocoon 2
Date Wed, 05 Feb 2003 17:44:32 GMT
Gianugo Rabellino wrote:
> Pier Fumagalli wrote:
>> "Pier Fumagalli" <> wrote:
>>> Ouch... I _knew_ I forgot somethin0g yesterday night, well, time to do a
>>> small addition (craps, I have to _really_ learn how to use the Wiki 
>>> now):
>> I did: <>
> Cool!
> How about adding a few lines about enabling caching on the proxy 
> (mod_cache) and coupling it with the explanation of the cache tuning 
> (expires headers) on the cocoon side? I can volunteer for the Cocoon 
> part, but I've never used the new mod_cache (I'm still in 1.3 land).

Don't want to rain on the party here, but I don't like the /static and 
mod_rewrite approach at all (sorry Pier), but I'd much rather see a 
transparent proxy setup like the one that Gianugo hints above.

Why? simple: if you do use mod_rewrite up front to have all *.jpg served 
from the local disk you have several problems:

1) dynamic image generation (think of image gallery thumbnails) doesn't 

2) the URI space of the static resources must be mapped *directly* into 
the disk.

3) it's *not* future compatible (think of /images/logo being rendered 
differently depending on the user agent)

4) it forces people to work on two different environments, one for 
static files, one for dynamic ones, making it more difficult to migrate 
one into another.

The best solution should be a proxy-ing rock-solid HTTP stack up front 
with a light-speed binary-oriented cache and cocoon doing *all* the 
resource generation (and avoiding to cache binary results itself).

*THIS* is the nirvana of the web serving architectures, because it 
follows the REST architectural practices, it's friendly with unlimited 
proxy distribution (think of backbone proxying in between your request 
and the hosting server)

designing the URI space so that it routes around technological problems 
is a potentially *very* dangerous approach and I don't like it.

the transparent proxy/cache solution *is* the key and reduces 
administration overheads (and worldwide load distribution problems) by 
orders of magnitude.

Please, don't get me wrong: Pier suggestions are great and I'm so glad I 
  convinced him to come back to work here on cocoonland, but we must not 
sit on those sysadmin tricks (even if clever and powerful) we must 
design a system that stands the pressure both from a technological *and* 
a human point of view.

So, the URI space should be designed with *NO* technological constraints 
imposed by the architecture.

Just stating this loud and clear.

Stefano Mazzocchi                               <>
    Pluralitas non est ponenda sine neccesitate [William of Ockham]

To unsubscribe, e-mail:
For additional commands, email:

View raw message