Gianugo Rabellino wrote:
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.Pier Fumagalli wrote:Cool!"Pier Fumagalli" <[EMAIL PROTECTED]> 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: <http://wiki.cocoondev.org/Wiki.jsp?page=ApacheModProxy>
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).
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 work.
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 <[EMAIL PROTECTED]>
Pluralitas non est ponenda sine neccesitate [William of Ockham]
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
