Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Sender: niclas@saturn.ewarna.com
Message-ID: <3A231B06.BAB70D30@localbar.com>
Date: Tue, 28 Nov 2000 10:40:06 +0800
From: Niclas Hedhman <niclas@localbar.com>
Organization: Bali Automation Sdn Bhd
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: [RT] Cocoon in cacheland
References: 
 <3390FF2B0DE0D21183B30008C70D751A022D1890@SAGEMSG0003.sagemsmrd01.sa.gov.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Stevenson, Chris (SSABSA)" wrote:

> > I think *now* is the time to start a discussion on it however,
> > because before anyone (be it me or anyone else) starts implementing
> > the caching architecture, we need to have worked out some of
> > the technical details.
>
> Hear hear!
>
> I remember Stefano's original post, and I appreciate this as
> well, but I am left with a nagging doubt. This is, no-one
> has convinced me that we need 'Internal Caching'.

I agree.

There was a long discussion about this some 6-12 months ago, perhaps
longer, where the task is a lot more complicated than what at first
seems to be the case (even the color of the goldfish may become
relevant).

I agree with Paul's initial assertment that external caching should be
looked at very closely, BUT again there are nice traps in that too.
Does the HTTP 1.1 caching architecture takes User-Agents into account?
I don't know, but it is this that is the foundation on which Cocoon once
was created. Different content to different users.

Next, the internal caching introduces domino effects, where changes
early in the chain invalidates the cache, and any management will be
wasted.

I suggest that the old thread is reviewed, because it exposed a whole
serie of traps. My suggestion is to only handle;

a) hasChanged( request ) from each component, if all answer NO, then
send back the full response.

b) Each component, especially the dynamic ones, uses an "intelligent"
approach to hasChanged(). Most data does not need to be signaled
changed, even if it has. It could delay that change a couple of
seconds/minutes, to allow more hits. The application decides. So in case
of the SQL handling, it needs to be given hints on the "death-span" of a
dataset, i.e. how long can this data be considered valid AFTER a change.


After the previous debate, I was pretty much convinced that the
complexity of advanced schemes would introduce too much bugs, where the
cached page would be, or not, sent when it was not supposed to. The
intermediary caching will send Cocoon into Giga Byte land for sure,
meaning more objects to disk, meaning slower cache response. And
finally, I believe that the above will introduce enormous speed benefits
for static content, just like C1, and reasonable speed improvements for
dynamic content.


Niclas