cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@sundn.de>
Subject AW: [C2]: Proposal for caching
Date Fri, 26 Jan 2001 09:23:58 GMT
> Stuart Roebuck wrote:
> 
> 
> This is probably impossible, but I'll suggest it anyway.  Let's 
> imagine that every component has a validator method.  When each 
> match pipeline is being validated (to see whether to use the 
> cache or not), the validation works backwards up the pipeline.  
> So for a pipeline like:
> 
>     <map:match="test"> 
>       <map:generate src="http://myserver/resource.xml" /> 
>       <map:translate src="local.xslt" />
> 	 <map:translate src="xsltwithxsp.xslt" />
> 	 <map:serialize type="html" />
>     </map:match> 
> 
> The serializer is asked to validate.  Its inbuilt validate method 
> somehow responds saying, "I've not changed if the previous 
> component hasn't changed".
> The XSLT translator (which has some external inputs) says, "I've 
> changed regardless of my input".
> The next translator up says "I've not changed unless the previous 
> component has changed".
> The generator says "I've not changed."
> So the cached result of the first translator is fed into the 
> pipeline and processing continues as normal from there.
> 
I am not quite sure, but why to you need the reverse order? Starting
with the generator saying "I'Ve not changed", going to the translator
saying "Not changed regardless of my input" and then the xsl translator
says "I've changed". No the result of the first translator (= the last
component which says: "Not changed") is used.
A component in the pipeline is only asked if the all previous components
have said: "Not changed".
This should create the same result, or am I wrong?

> Now, if we want to add in some specialist caching behaviour we 
> have an option of adding in an optional 'cache' component like this:
> 
>     <map:match="test"> 
>       <map:generate src="http://myserver/resource.xml" /> 
>       <map:translate src="local.xslt" />
> 	 <map:translate src="xsltwithxsp.xslt" />
> 	 <map:cache>
> 	  <map:parameter name="maxUpdateFrequency" value="6 hours" />
> 	 </map:cache>
> 	 <map:serialize type="html" />
>     </map:match> 
> 
> Now, the same process as before takes place, but when the 'cache' 
> component is asked to validate, it will normally just say, "I've 
> not changed". In this example, once every 6 hours it will say, 
> "I've changed if my input has changed".  If it says, "I've not 
> changed" then the cached value of its last result is used without 
> even having to call the validators further up the pipeline.
>
The same applies here: Why not starting with the generator and going
the usual order of the pipeline`?
 
> If this idea was possible it would provide a very simple 
> framework:  all components have validators;  specialist 
> validators exist as stand-alone cache components; the actual 
> caching is carried out automatically.
> 
I like this idea of the special cache components a lot as it would make
the sitemap design easier. But the main problem I see in this case is the
generator:
The FileGenerator can read a local file from harddisc and it can get XML
over http from another server. For a local file the generator can easily 
detect if the file has changed by looking at the last modification date.
For external XML it is in many cases not possible to test if the source
has changed. So for such cases the special cache component is very useful.
The FileGenerator would say: "Has not changed" and the special cache
component would say: "Content changes every 6 hours".
But how does the FileGenerator know that he should say "Has not changed"?
I see four possibilites:
1. The FileGenerator has its own logic, saying: I can test local resources
   myself, external resources do never change.
2. Same as above, but external resources change always
3. Configuration of the file generator:
      <map:generate src="http://myserver/resource.xml">
		<map:parameter name="cache-has-changed" value="always"/> <!-- or never -->
4. The special cache component is tied to a pipeline component:
       <map:generate src="http://myserver/resource.xml"> 
 	 <map:cache>
 	  <map:parameter name="maxUpdateFrequency" value="6 hours" />
 	 </map:cache>
	</map:generate>
   If a component has a special cache component that would do the testing, if not,
   the component tries it itself, by using 1. or 2.
Personally I like 4. the most, as it is very close to the validator concept I posted
yesterday.
Perhaps this is again FS, but it is very straight forward and easy to implement.


Carsten


Mime
View raw message