Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <911C684A29ACD311921800508B7293BA0221DB83@cnmail>
From: Geoff Howard <ghoward@crosswalk.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: [RT]: Calculating the cache key
Date: Wed, 22 May 2002 13:05:09 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"

Regarding compound integer keys...

Berin wrote-

> Consider a compound key that has an int for each part.  That integer
> is made up of the top half marking the component ID (there will be less
> than 65,536 unique types of components), and the unique entry within
> that component (another 65,536 entries).  We can shift the balance
> as necessary, but keep up.  A compound key has one part for each
> component that is part of the pipeline.  Something like this:
> 
> 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?

2) Who would create and who would hold these keys?

3) Does each element need to keep track of all previous elements (as in your
example I think), or only the one immediately preceding it?  If the
serializer depends only on the transform before it, would it be smarter to
only reference that, and then ask that what it depends on?

Geoff

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