On Mon, 14 Apr 2008, Tobias Schlitt wrote: > On 04/07/2008 09:25 PM Tobias Schlitt wrote: > > > I just finished a the first draft of my design for hierarchical (multi > > level) caching in the Cache component. Please take some minutes and > > review my proposal. You can find the RST in SVN under > > > trunk/Cache/design/design-1.4.txt > > > and a generated HTML version under > > > http://schlitt.info/ez/cache_design-1.4.html > > I updated the design according to the discussions here on the list and > to those on IRC. This resulted in some major changes. Please review the > design again under the locations named before.
Some minor comments: > Replacement strategies > ---------------------- > > [snip] > > A problem with any of the replacement strategies is, that additional > information about a cache item needs to be stored. For example: To > realize an LRU algorithm, the last access time of an item needs to be > stored. For LFU, the number of accesses needs to be stored. The cache > storages currently don't support adding such information and an > appropriate place to store this persistently and efficiently needs to be > thought out. For file based caches, the filesystem already keeps track of the last access time, so it doesn't have to be stored separately. Perhaps it'd be possible to only use the extra information when it's actually used. So for LRU and the file based caches, you don't really need to store anything; while you would need it for LFU and file and others. > Cache propagation > ----------------- > > There are two possibilities to define propagation of cache items through > the stack, where a decision needs to be made for one consistent > solution: I thought we decided on going only with "Propagate in store" ? > ezcCacheStack > ------------- > > [snip] > > This also ensures, that caches are not stacked recursively, since > ezcCacheStack won't implement this interface itself. Is it actually a problem if there are multiple stacks that are hooked up together? > The given $id parameter must be a string or integer which identifies the > given storage uniquely in the stack. Couldn't we just pre-generate this number a-la auto increment? > It needs to be clearified, if restored items should be bubbled up to > higher storages. Why wouldn't we want that? regards, Derick -- Components mailing list [email protected] http://lists.ez.no/mailman/listinfo/components
