On Thu, 17 Apr 2008, Tobias Schlitt wrote: > On 04/16/2008 08:53 PM Derick Rethans wrote: > > On Wed, 16 Apr 2008, Tobias Schlitt wrote: > >> On 04/16/2008 08:05 PM Derick Rethans wrote: > >>> On Mon, 14 Apr 2008, Tobias Schlitt wrote: > >>>> On 04/07/2008 09:25 PM Tobias Schlitt wrote: > > >>>> 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" ? > >> > >> Still the 2 possibilities are mentioned. This is just the requirements > >> section and it just states that we had to possibilities for the design > >> here. The design itself should only describe the method we decided for. > > > > It's in the design document, perhaps they should be split up then? > > I can split it up, if you insist to it. The initial idea was that the > feature is not too large and therefore the requirements document can be > integrated into the design.
It's 6 pages - I'd say that's big enough :-) > >>>> 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? > >> > >> What if the user changes the order? How will we notice? This would > >> require us to store this information in the storage in addition. > > > > I didn't see any functions for reordering them, so how is this a > > problem? > > $storageA = $stack->popStorage(); > $storageB = $stack->popStorage(); > $stack->pushStorage( $storageA ); > $stack->pushStorage( $storageB ); K, didn't see those. Instead of a number, could we use a string perhaps? > >>>> It needs to be clearified, if restored items should be bubbled up > >>>> to higher storages. > >>> > >>> Why wouldn't we want that? > > >> Because it costs time again. Imagine a 4 level stack, where file system > >> is the lowest and largest one. Each time an item would be restored from > >> the there, it would be placed in 3 higher storages again. Not sure if we > >> want this, since it slows down the read process. > > > I think this is one of the major things why you'd want a stacked > > cache... so yes, I definitely think it should be stored in higher > > storages. Perhaps we can add an option to restore() to *not* do that, > > but I do want the general case to store it in the higher caches. > > I think the parameter for restore() idea is not good. Let's better add > an option to the stack to determine this. I'll add this to the design > and will think about it some more, if it could not make any problems. No, it can't be done on the stack - it should be done on each engine *in* the stack. However, the default should be to bubble it up. regards, Derick -- Components mailing list Components@lists.ez.no http://lists.ez.no/mailman/listinfo/components
