cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergio Carvalho <scarva...@criticalsoftware.com>
Subject Re: idle thoughts in caching in c2
Date Tue, 23 Jan 2001 15:11:05 GMT
On Mon, 22 Jan 2001 23:16:47 +0100
Giacomo Pati <giacomo@apache.org> wrote:

<snip/>
> 
> I think this is not the concern of a sitemap maintainer. Instead an more
> intelligent ResourcePipeline class should be able to determine the
> caching strategy by looking at interfaces and calling methods on a
> generator/transformer.

Before anything else, I strongly disagree with automatic determination of caching strategy.
It will make generator/transformer design more complex, and we'll get a less flexible system.
I want to be able to choose caching strategy when I design the site, not when I design components.


Imagine some generated content, which can be checked with 'last-modified', but that I *know*
changes once a week. I can save 20ms/request (a standard HTTP header request) just by choosing
my own cache policy for that content. 20ms is short, but if you're aiming to answer in 200ms
(my own standard), you just saved almost 10% of the response time. And this special cache
policy will be used only in this specific case and can't be defined when the generator is
designed.

Ok, I guess I didn't see the sitemap maintainer the same way as you do. The sitemap lends
itself to be associated to a visual tool, thus bringing web application development to the
visual-RAD stage, which is great. This would bring sitemap maintenance to non-technical or
just-technical-enough users. 

But, right now, you can't say that sitemap maintenance can be handed over to a non-technical
user. It's a text-based interface, which is reason alone to scare most non-techies. Aiming
textual sitemap maintenance to a non-techie is an utopy and an error, I believe. 

Assuming textual sitemap maintenance is for techies, then why not have the sitemap completely
describe the page building process, and then build on top of it to get a non-techie user friendly
interface to building sitemaps? I guess the whole question boils down to whether we wish non-techies
to use the textual sitemap. I say we don't. 

We could reach middle ground here, by (optionally) associating each generator/transformer
(geformer?) with a cache, on the sitemap. Cocoon uses the cache defined in the sitemap, if
it is there, or uses deduced cache if the cache definition is missing.

<snip/>
> > I don't think HTTP caches are a solution here. Cocoon doesn't use HTTP for
> > intermediate steps, so HTTP caches cache the whole page; which is useful but
> > doesn't go as far as we need. I want Cocoon caches to be able to store
> > intermediate steps (like menu generation, for example).
> 
> If your XML/XSP page is static (or static for a certain amount of time)
> and you put a http cache (proxy) between your clients and cocoon and
> you'll be able to use proxy headers (last-modified, exceeds) or might
> react on request header (if-modified-since) to speed up processing (as
> the ResourceReader class is doing). 

This doesn't go against what I say above. HTTP caches are useful, but not as useful as Cocoon
caches can be, since Cocoon caches are part of the content generation and can cache document
components (a database generated menubar is a recurrent example).

--
Sergio Carvalho
---------------
scarvalho@criticalsoftware.com

If at first you don't succeed, skydiving is not for you

Mime
View raw message