cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian May <>
Subject Re: [Cocoon Devel]Is Cocoon2 caching implemented?
Date Tue, 15 Aug 2000 23:42:04 GMT
>>>>> "Hans" == Hans Ulrich Niedermann <>

    Hans> [ XSLT-specific caching internals/proposals deleted ]

    >> 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?

Not sure I like the max() part. 

I think it might be better to parse the caching details along each
pipeline component (in a similar way I presume that the data is passed
along), so each component can inspect the details from the previous
component, and modify the details appropriately. So a component could
say that the expiry date = prev expiry date - 10%, for instance.

Of course, I haven't seen the sitemap code, so I am not sure about how
this would be implemented.

    Hans> Sounds good to me. I've thought about caching during the
    Hans> last few weeks (without having a look into existing caching
    Hans> code) and came up with a similar method but that didn't go
    Hans> that far.

    Hans> However, the getLastModified() and getWhenExpires() methods
    Hans> probably have to know about request parameters (URI params,
    Hans> Post stuff, cookies, sessions etc.) to determine if the
    Hans> output data has changed.

Thats an interesting idea that takes it beyond what I was thinking of.
This should allow very fine tuning of how long a page can be cached
for. The more I here about C2, the more I like it ;-)

Some things to consider: some pages don't need to expire. I guess you
can just give them a very advanced expire date. However, are there any
pages that should never be cached? I can't think of any off hand...

Another thing to think about: how do you set the expiry time for
static files. Perhaps expire date = lastmodified + config value.
As, IMHO, this depends on the largely on the administrators of the
site, and how often they plan to make changes.

    >> 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.


Also, it would be really good (for some broken applications) if the
pipeline stage can pass the caching details on without modification.
This is one problem I have had with Apache. My university has a
(stupid) policy that all personal web pages needs to be processed by a
CGI script that appends a legal disclaimer to bottom. However, this
means that the file can't be cached. Arggh!

[ however, I must admit this raises other issues that don't appear to
be a priority (yet?), eg serving personal pages with Cocoon ]

    Hans> But this suggests adding a third method to all pipeline
    Hans> components that tells the cache engine if caching results
    Hans> makes any sense at all (imagine a component that outputs the
    Hans> current time).

This depends on how accurate the time needs to be. If you had a web
page designed for synchronising your watch to the second, then maybe
this might be an issue...
Brian May <>

View raw message