cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart Roebuck <stuart.roeb...@adolos.co.uk>
Subject Re: AW: [C2]: Proposal for caching
Date Thu, 25 Jan 2001 15:30:46 GMT

On Thursday, January 25, 2001, at 02:40 PM, Carsten Ziegeler wrote:

> From: "Carsten Ziegeler" <cziegeler@sundn.de> 
> Date: Thu Jan 25, 2001  02:40:16 PM Europe/London 
> To: <cocoon-dev@xml.apache.org> 
> Subject: AW: [C2]: Proposal for caching 
> In-Reply-To: <3A7027E3.49372E28@apache.org> 
> Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm 
> List-Help: <mailto:cocoon-dev-help@xml.apache.org> 
> List-Unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org> 
> List-Post: <mailto:cocoon-dev@xml.apache.org> 
> Delivered-To: mailing list cocoon-dev@xml.apache.org 
> X-Priority: 3 (Normal) 
> X-Msmail-Priority: Normal 
> X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) 
> Importance: Normal 
> X-Mimeole: Produced By Microsoft MimeOLE V5.50.4522.1200 
> X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 
>  
> > Berin Loritsch wrote 
> > > OK, now I get what you meant. I think it is really a good idea. It would 
> > > lead to a repository of possible, configurable validators (equivalent 
> > > to the repository of generators, transformers etc.) and the sitemap 
> > > designer chooses the right validator for the component. 
> > > But it is not possible to write validators which are usable for any 
> > > component as only the component knows which data to test. So you 
> > > have a tight coupling between a component and its validators. 
> >  
> > If there is a tight coupling between validators, then we need to look at 
> > coupling them.  More down below. 
> >  
> > > Quickly thinking I see a possible solution: 
> > > Each component declares his own usable validators which can only be used 
> > > with this component: 
> > >  
> > > <map:generators> 
> > >     <map:generator label="content" name="file"  
> > src="org.apache.cocoon.generation.FileGenerator"> 
> > >         <map:validators> 
> > >            <map:validator name="fileChangedValidator" class  
> > ="org.apache.cocoon.validation.FileChangedValidator"/> 
> > >            .... 
> > >         </map:validators> 
> > >     </map:generator> 
> > > <map:generators> 
> > > ... 
> > >    <map:match="test"> 
> > >      <map:generate src="http://myserver/resource.xml" 
> > >           type="http" 
> > >            validator="fileChangedValidator"> 
> > >      </map:generate> 
> > >       ... 
> > >    </map:match> 
> > >  
> > > What do you think about this? 
> >  
> > I think that modifying the sitemap like this only serves to make 
> > things more confusing or at least cluttered.  I understand the 
> > idea of swapping Validators, but I think that might be flexibility 
> > syndrome.  How many ways is a FileGenerator going to invalidate 
> > a cache entry for a File?  I do think they should be external 
> > components, but I also think that they should be hard-wired to 
> > the Component. 
> >  
> > FileGenerator { 
> >    Validator validator = new FileChangedValidator(); 
> >  
> >    ...... 
> >   
> >    generate() { 
> >       if (validator.hasChanged(file) { 
> >           // normal processing 
> >       } else { 
> >           // retrieve from cache. 
> >       } 
> >    } 
> > } 
> >  
> OK, perhaps a file generator is a bad example, lets take the SQLTransformer. 
> There might be different use cases for it: 
> - The content is invald every day at 6 in the morning 
> - The content is valid four 3 hours 
> - On weekdays the content is valid for 2 hours and never changes on sat./sun. 
> Perhaps this is FS using different validator classes. My first thoughts 
> were, that there is a base abstract ValidatorClass which can handle all of that 
> above. Each component is coupled with its own validator (like in your example  
> above) and it can (not must) be configured in the sitemap: 
>     <map:match="test"> 
>      <map:generate src="http://myserver/resource.xml" type="http"> 
> 		<map:parameter name="validator_valid_period" value="3 hours"/> 
>      </map:generate> 
>             or 
>      <map:generate src="http://myserver/resource.xml" type="http"> 
> 		<map:parameter name="validator_invalidate_at" value="6 in the morning"/> 
>      </map:generate>      ... 
>    </map:match> 
> But in this case it is required that each validator has some basic functions like 
> them above. 
> I like this approach more than the pool of validators as the sitemap designer 
> has not to care about validators. He uses only some simple parameters. 
> The pool-approach is more flexible and allows custom validators which can do 
> whatever they want. 


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.

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.

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.

In this model, the validator method really amounts to generating a hash-code based on its
dependencies.  The hash code is the key used by the automatic caching mechanism.

Stuart.


-------------------------------------------------------------------------
Stuart Roebuck                                  stuart.roebuck@adolos.com
Lead Developer                               Java, XML, MacOS X, XP, etc.
ADOLOS                                             http://www.adolos.com/
Mime
View raw message