cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@betaversion.org>
Subject Re: [RT] sharing latest research production (long!)
Date Tue, 06 Mar 2001 13:04:44 GMT
Zitiere Stefano Mazzocchi <stefano@apache.org>:

> Giacomo Pati wrote:
> > 
> > > Isn't is smart? :)
> > 
> > Well, we thought is is a little bit overdesigned so here is our smart
> > solution :-)) we (Daniel and I) developed (I've announced this prior
> to my
> > vacations)
> > 
> > Imagine a CachableXMLProducer implements the following interface
> > 
> >   public interface CachableXMLProducer {
> >     Object getKey()
> >     CacheValidity getValidity();
> >   }
> > 
> > The getKey method returns an object, that uniquely identifies the
> universe
> > the XMLProducer is in. For a FileGenerator its probabbly the file it
> is
> > parsing. A TraxTransformer returns the name of its stylesheet. Other
> Producer
> > return appropriate Objects.
> > 
> > Take into accound that the CacheManager will use this Object together
> with
> > the type of Producer to get a unique Key into its CacheStore.
> > 
> > The getValidity returns a CacheValidity objects that has a single
> isValid()
> > method (more of this later on).
> > 
> > The process of determining if a ChacheEntry is still valid goes like
> this.
> > 
> > The CacheManager asks the CachableXMLProducer to return its key
> (getKey()).
> > This key together with the type of XMLProducer the key came from is
> used as
> > index into a ValidityStore which holds CacheValidity objects gotten so
> far.
> > If there is no CacheValidity object corresponding no CacheEntry has
> been
> > taken so far. If there was a stored CacheValidity object it is passed
> to the
> > CacheValidity object obtained by a call of the getValidity method of
> the
> > CachableXMLProducer:
> > 
> >    Object key = cachableXMLProducer.getKey();
> >    if ((validity = validityStore.get(key, cachableXMLProducer)) !=
> null) {
> >        newValidity = CachableXMLProducer.getValidity();
> >        if (newValidity.isValid(validity)) {
> >            // previous CacheEntry is still valid
> >        } else {
> >            // previous CacheEntry is invalid
> >        }
> > 
> > Now lets talk about the CacheValidity object.
> > 
> >   public interface CacheValidity {
> >     boolean isValid (CacheValidity validity);
> >   }
> > 
> > Important is, that the isValid() method of a CacheValidity object can
> only
> > compare to exactly the same type of CacheValidity object. The
> algorithm used
> > by the cache manager above should ensure that only the same type of
> > CacheValidity objects are used. This means also that a specific type
> of a
> > CachableXMLProducer can only generate the exact same type of
> cachevalidity
> > object all the times. The design with the CachePolicy of Ricardo and
> Stefano
> > allows this but we think it is not a good idea.
> > 
> > Almost 80% of them will be TimeStampValidity objects as in the case of
> the
> > FileGenerator or TraxTransformer. So a concrete TimeStampValidity
> class will
> > take care of these type of validities.
> > 
> > You can think of all kinds of validities you need.
> > 
> > Additionally you can have a ValidityContainer class which can hold
> several
> > Validity objects and return an ANDed value of all the Validity objects
> as
> > well as an OrValidityContainer which ORes those validation results.
> > 
> > We thought this design is very simple to implement and fast as well.
> It also
> > allows every boolean constellation to be implemented to check the
> validity.
> 
> Your solution doesn't address one problem, tought: key generation is
> left to the component implementor and might result in slow and memory
> consuming implementations.

I can see your point but given the fact that more than 80% (maybe over 90%) of 
all keys that will ever be generated are simple object like a timestamp or a 
string (from the view of a Component) I think it's good enought. Remember that 
the key a Component has to generate must be unique only within that Component 
itself not over the hole cache system. The "real" key into the cache system is 
generated by the cache system itself taking the key from the component together 
with the component name (class name and type name).

> This is why, in our solution, we re-invert the control: you tell us
> what
> you depend on and we create the key for you.
> 
> But I resonate with the design paradigm of your CacheValidity
> object....
> hmmm, maybe the two things can be merged together?

Yes, rethink about it :) our approach is a splitted key generation mechanism. A 
component has to "generate" a key that's only unique in it's own universe, 
nothing more so quite simple from the perspective of a component writer.

Giacomo

Mime
View raw message