cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: idle thoughts in caching in c2
Date Mon, 22 Jan 2001 22:16:47 GMT
Sergio Carvalho wrote:
> 
> On Mon, 22 Jan 2001 11:09:41 +0000
> Paul Russell <paul@luminas.co.uk> wrote:
> 
> > * Sergio Carvalho (scarvalho@criticalsoftware.com) wrote :
> > > On Fri, 19 Jan 2001 13:44:42 -0500 (EST)
> > > Donald Ball <balld@webslingerZ.com> wrote:
> > > > do you mean that the caching components should be explicitly put in the
> > > > pipeline in the sitemap:
> > > >
> > > > <map:cache type="lru"/>
> > > Yes. A Cache interface could be defined, so that classes implementing
> > > caching are identified. Then, these are placed in the pipeline,
> > > between each data-producer (or processor) and the subsequent
> > > data-consumer.

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.

> >
> > That makes sense. Would we then stick a binary cache on the output
> > regardless, or should that be explicit too? (Or do we not put a binary
> > cache on at all, and leave it to an http level cache?)
> 
> What are you calling a binary cache? Storage of the document in binary form?
> Is it possible to do a memory snapshot in Java, as it is sometimes used in C
> to avoid parsing cached data?
> 
> 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). 

> 
> There is another design refactoring possible here, but it is probably an
> overkill: In this caching model, a cache class handles two things, cache
> policies and cache storage. Truly, in OO design, these should be handled
> separately, and used through delegation. Something like having these classes:
> 
> - Policies:
>   TimeToLiveCachePolicy
>   FileDirtyCachePolicy
>   FooBarCachePolicy
> - Stores:
>   MemorySnapshotCacheStore
>   TextCacheStore
>   RDBMSCacheStore
> 
> And then have small&simple cache processors that delegate in one policy class
> and one store class:
>   TimeToLiveOnMemorySnapshotCache
>   TimeToLiveOnTextCache
>   FileDirtyOnMemorySnapshotCache
> 
> Again, this is probably an overkill.

Or future refinements/enhancements :)

> 
> I promise I'll implement/aid implementing some of these ideas in mid-february,
> if there's no cache in C2 by mid-february, when my current project finishes
> and I get time to breathe.

Cool, we'll remember this for sure :)

Giacomo

Mime
View raw message