cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: Is Cocoon2 caching implemented?
Date Mon, 14 Aug 2000 20:42:45 GMT
"Stevenson, Chris (SSABSA)" wrote:
> 
> >     >> Personally, my major concern for Cocoon 1 (and so far Cocoon
> >     >> 2), is that static web pages do not have the http
> >     >> "Last-Modified" header.
> >
> >     Stefano> This is a matter or writing a new serialier (or improving
> >     Stefano> on existing ones) that is able to do this... there is
> >     Stefano> nothing in the C2 architecture that doesn't allow you to
> >     Stefano> do that.
> 
> > 1. what "last modified" header to use.
> >
> > 2. Also when to use the "expires" header (dynamic pages should expire)
> > might be an issue.
> >
> > I am guessing that 2 could be specified in the sitemap, however 1,
> > might be harder. You could have the last-modified date of the XML
> > file:
> >
> > last-modified(out.html) = last-modified(in.xml)
> >
> > or the XSL file:
> >
> > last-modified(out.html) = last-modified(in.xsl)
> >
> > Or perhaps something like:
> 
> What about adding behaviours like
> 
> getLastModified()
> getWhenExpires()
> 
> to each pipeline component, that returns a null by
> default, then have the sitemap work out max()
> by calling each in turn?
> 
> This makes more sense to me because the idea of
> modification time belongs on the component
> (be it generator, filter or serializer) and
> not at the sitemap level...
> 
> For example, suppose there is a filter that uses
> some time-based criteria to change the way it
> generates a file (maybe black bg for evening,
> yellow for daytime). No files change, but the
> last-modified *does* change.
> 
> This could also be used to abstract out the
> re-compilation and caching tests - you just call
> getLastModified() on each pipeline component,
> and if it is later than the cached version,
> mark the pipeline as dirty.
> 
> This is also more general than the current
> hasChanged() on sitemap..
> 
> again for example, suppose there are two or more
> caches reading from the same sitemap object,
> maybe on a distributed system... calling
> hasChanged on the sitemap will cause inconsistent
> behaviour, since the first call will reset to false,
> and the next cache to call hasChanged() will think
> nothing has changed.
> 
> this would mean a change to the interface of
> SitemapModelComponent and SitemapOutputComponent.

I like this and I agree the two semantics

> getLastModified()
> getWhenExpires()

cannot be ignored on any resource.

NOTE: both modification time and expiration time must indicate the
component "behavior", not the files that they use.

This is impossible to estimate when using XSLT extentions and this is
another reason to avoid XSLT extentions in favor of XSP, since in XSP
you can specify code to implement these methods directly while you
cannot with XSLT extentions.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------



Mime
View raw message