cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [RT] sharing latest research production (long!)
Date Tue, 06 Mar 2001 14:19:10 GMT
Giacomo Pati wrote:

> > 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).

ah, ok, you flatten it to only one dependency. What worries me the
assumption that 90% of the cases will have only one dependency. I have
the feeling this might not be the case, but I can't prove this.
> > 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.

Ok, sounds good enough for me.

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche

View raw message