Hi!
On 04/10/2008 09:59 AM Derick Rethans wrote:
> On Wed, 9 Apr 2008, Tobias Schlitt wrote:
>> On 04/09/2008 02:13 PM Derick Rethans wrote:
>>> On Mon, 7 Apr 2008, Tobias Schlitt wrote:
>>>> - **Bubbling restored data up through the cache stack**
>>>> According to the replacement strategy, cache items need to be placed into
>>>> higher levels of the hierarchy, as soon as they get restored from a
>>>> deeper
>>>> level, to make them available faster on subsequent restore requests. For
>>>> more
>>>> information see the `Replacement strategies`_ section.
>>> Sometimes you might not want the items stored in a higher stack level,
>>> for example because of data size reasons. As an example, you want a 1mb
>>> PDF file stored in a cache on disk, but definitely not in the memory
>>> cache. How are we going to handle this?
>> You need to create a dedicated cache storage for these files.
> Why? I'm saying that this should be an option of every cache storage
> that we have. Creating a whole new storage backend for just doing this
> seems silly. I think it's particulary important for the memory caches
> (in-memory, apc, shared-mem).
It will overcomplicate the whole process, if you create such exceptions.
In fact you need to either check the size of the data to store
(impossible inside PHP) or need to devide by attribute or something, in
which levels an item might be stored. This also unnecessaty raises
complexity of the storage process, which again reducec performance.
I also do not see a problem to create a dedicated storage for this. In
fact you just need to create a new directory on your HD and instatiate
the object. If you need such large items to be stored, you most probably
want to store them on the HD anyway, so a dedicated storage that does
not involve the overhead of the stack is desired here.
>>>> ezcCacheStack
>>>> -------------
>>>>
>>>> An object of the ezcCacheStack class is the main instance to provide the
>>>> hierarchical stack mechanism. The stack object takes care of managing
>>>> several
>>>> cache storages, the unified access for storing and restoring cache items
>>>> and
>>>> the associated objects needed to realize this.
>>> [snip]
>>>> class ezcCacheStack extends ezcCacheStorage
>>>> {
>>>> public function __construct( $location, $options );
>>>> public function store( $id, $data, $attributes = array() );
>>>> public function restore( $id, $attributes, $search );
>>>> public function delete( $id, $attributes, $search );
>>>> public function countDataItems( $id, $attributes );
>>>> public function getRemainingLifetime( $id, $attributes );
>>>>
>>>> public function getStackedCaches();
>>>> }
>>> I miss a method to add a new storage to the stack. I know you mention
>>> this as an option in "ezcCacheStackOptions", but I don't think this fits
>>> as an option easily. I would go for a method that adds a new storage
>>> configuration to the bottom of the "stack" here.
>> I don't see the sense here. In general you want to configure the stack
>> once and be happy to never change it. Could you give me an example of a
>> use case of such a method?
> Sure, I think it's just simpler to use then a deeply nested options
> array:
> <?php
> $stack = new ezcCacheStack();
> $options = $stack->options = new ezcCacheStackOptions;
>
> $apcOptions = new ezcCacheStackStorageConfiguration;
> $apcOptions->class = 'ezcCacheStorageApcPlain';
> $apcOptions->itemLimit = 512;
>
> $memCacheOptions = new ezcCacheStackStorageConfiguration;
> $memCacheOptions->class = 'ezcCacheStorageMemcachePlain';
> $memCacheOptions->location = '27.0.0.1';
> $memCacheOptions->itemLimit = 1024;
>
> $fileOptions = new ezcCacheStackStorageConfiguration;
> $fileOptions->class = 'ezcCacheStorageFileArray';
> $fileOptions->location = '/var/cache/foo';
>
> $options->storages = array(
> $apcOptions,
> $memCacheOptions,
> $fileOptions
> );
> ?>
> vs.:
> <?php
> $stack = new ezcCacheStack();
> $stack->addStorage( 'ezcCacheStorageApcPlain', null, 512 /*, $extraOptions */
> );
> $stack->addStorage( 'ezcCacheStorageMemcachePlain', 'localhost', 1024 );
> $stack->addStorage( 'ezcCacheStorageFileArray', '/var/cache/foo' );
> ?>
I agree that this is simpler. See below for further comments.
>>>> interface ezcCacheStackableStorage
>>>> {
>>>> restoreMetaInfo();
>>>> storeMetaInfo( array $metaInfo );
>>>>
>>>> purge();
>>> Maybe we can add an option to purge() to clear out the whole cache?
>> I would suggest to add another method for this, named empty() or something.
> You can't really use empty() though, as it's most likely a reserved
> keyword.
What about clean()?
>>>> ezcCacheStackOptions
>>>> --------------------
>>>>
>>>> An object of this class is used to configures the cache stack. It extends
>>>> the
>>>> ezcCacheStorageOptions class, to be compatible with all other mechanisms.
>>>> The
>>>> 'ttl' and 'extension' options are ignored, because each of the stacked
>>>> caches
>>>> must be able to implement its own set of options. The following options are
>>>> part of this class:
>>>>
>>>> 'storageStrategy'
>>>> This option contains a class name, which is to be instantiated to
>>>> perform
>>>> storage operations in the stack. The class must extend the abstract
>>>> ezcCacheStackStorageStrategy class.
>>>> 'storages'
>>>> This option is an array of ezcCacheStackStorageConfiguration objects,
>>>> that
>>>> will be used to define the cache storages contained in the stack. Per
>>>> default, no storages will be defined. In this case, a call to any of
>>>> the
>>>> methods defined by ezcCacheStorage will result in an exception.
>>> I don't think we should either of those options. As I just mentioned,
>>> storages should be maintained through methods and the first one,
>>> storageStrategy I suggest not to have at all to make the implementation
>>> easier. That means no different stack-storage-strategies.
>> If we go this way, we cannot support the delayed initialization
>> mechanism provided by ezcCacheManager for the stack. If this is ok, I
>> don't have a problem with it. ezcCacheStack would then not extend
>> ezcCacheStorage and we can design the API for it new from scratch.
> Why not? With the example above you can still store the parameters for
> all the storage backends in an array - but it's just not part of the
> options class, but just ezcCacheStack.
Hmmm... I think we should invent another level here, which creates a
cache stack as we desire on the fly. The solution of storing the storage
configuration in options is also error prone. I'll think some more about
this and define a better solution in the design document.
>>> One thing that I miss in the design is the performance impact on
>>> restoring items from the cache, perhaps you could add something about
>>> that?
>> You mean the overhead in using the stack at all?
> Yes.
Ok, I think this belongs to the documentation, later. However, I'll add
some remarks to the design doc, too.
Regards,
Toby
--
Mit freundlichen Grüßen / Med vennlig hilsen / With kind regards
Tobias Schlitt (GPG: 0xC462BC14) eZ Components Developer
[EMAIL PROTECTED] | eZ Systems AS | ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
