cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berin Loritsch" <blorit...@apache.org>
Subject RE: [RT]: Calculating the cache key
Date Thu, 23 May 2002 14:07:14 GMT
> From: Geoff Howard [mailto:ghoward@crosswalk.com] 
> 
> > > > 
> > > > p[0]=fe01b342 { FileGenerator, resource="hello.xml" }
> > > p[1]=fb021431 {
> > > > XSLTTransformer, resource="layout.xsl" } p[2]=fb02542e {
> > > > XSLTTransformer, resource="skin.xsl" } p[3]=fc010000 { 
> > > HtmlSerializer
> > > > }
> > > 
> > > 1) I just got that you are proposing a collection of compound
> > > keys -- compound meaning a bit mask/shift combination of two 
> > > shorts into a compound long.  How would this work for aggregators?
> > 
> > No, actually, I was suggesting an array of ints (or longs).  Each 
> > component has a unique ID, and that component can manage the ids it 
> > needs to worry about.
> > 
> 
> Yes, sorry looking back my comment wasn't clear.  What I was 
> catching on to was that each element of the array stored an 
> integer which seems to be storing two different values - one 
> in its 2 most significant bytes for the component, one in its 
> two least significant bytes for the unique key within that 
> component space - in your example a filename.  
> So, in the example above, the integer stored in p[1] is 
> 0xfb021431 and is an XSLTTransformer key.  The integer stored 
> in p[2] is 0xfb02542e, also an XSLTTransformer key, but with 
> a different resource.  If I understood you right, 
> 	p[1]>>>16 = p[2]>>>16 = 0x0000fb02 
> which is a unique hash meaning "XSLTTransformer" component. And
> 	p[1] & 0xFFFF = 0x00001431
> which is a unique hash meaning "layout.xsl".

Bingo! (Or as they say in Africa, Bango!)

> 
> What I was unclear of in the case of aggregators was: if your 
> first step in the example had been an aggregator instead of a 
> FileGenerator, and combined "hello.xml" and "goodbye.xml" 
> would you combine the hash for those two resources when 
> creating p[0], or do you have an extra element in your array:
> 
> 
> p[0]=fe03b342 { Aggregator, resource="hello.xml" } 
> p[1]=fe03abcd { Aggregator, resource="goodbye.xml" } 
> p[2]=fb021431 { XSLTTransformer, resource="layout.xsl" } 
> p[3]=fb02542e { XSLTTransformer, resource="skin.xsl" } 
> p[4]=fc010000 { HtmlSerializer }

Essentially yes.  However, keep in mind that an Aggregator
functions like a special purpose Generator.  (It is distinct,
but the function is equivalent).  Therefore, the Aggregator
could store the individual pipeline keys internally, so that
it can check validity from them.  In that case, you would
only need the key for the aggregator itself.

p[0]=ffff0001 { Aggregator, first in sitemap }
p[1]=fb021431 { XSLTTransformer, resource="layout.xsl" } 
p[2]=fb02542e { XSLTTransformer, resource="skin.xsl" } 
p[3]=fc010000 { HtmlSerializer }

Internal to the Aggregator would be two keys, representing the
pipelines for the "parts".

key[0][0]=fe03b342 { FileGenerator, resource="hello.xml" }
key[0][1]=fb021422 { XSLTTransformer, resource="hello2site.xsl" }

key[1][0]=fe03abcd { FileGenerator, resource="goodbye.xml" }

That way, only part of the Aggregator has to be rebuilt if one of
the subpipelines was messed up.


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message