Return-Path: Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm Delivered-To: mailing list cocoon-dev@xml.apache.org Received: (qmail 47152 invoked from network); 6 Mar 2001 15:22:31 -0000 Received: from pop.systemy.it (194.20.140.28) by h31.sny.collab.net with SMTP; 6 Mar 2001 15:22:31 -0000 Received: from apache.org (pv31-pri.systemy.it [194.21.255.31]) by pop.systemy.it (8.8.8/8.8.3) with ESMTP id QAA20306 for ; Tue, 6 Mar 2001 16:22:26 +0100 Message-ID: <3AA4F1DE.D8C2ECE1@apache.org> Date: Tue, 06 Mar 2001 15:19:10 +0100 From: Stefano Mazzocchi X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: cocoon-dev@xml.apache.org Subject: Re: [RT] sharing latest research production (long!) References: <3A8C616F.178F59D2@apache.org> <01030418025501.01088@lap1> <3AA4A7F3.D7D4300D@apache.org> <983883884.3aa4e06c57e77@mail.betaversion.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: h31.sny.collab.net 1.6.2 0/1000/N 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 --------------------------------------------------------------------