Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: local policy)
Message-ID: <417642C0.3030708@reverycodes.com>
Date: Wed, 20 Oct 2004 06:49:36 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: FilesystemStore broken???
References: <0MKuxu-1CK9m622aK-0005GX@mx.perfora.net>
In-Reply-To: <0MKuxu-1CK9m622aK-0005GX@mx.perfora.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Carsten Ziegeler wrote:
> One addition: doing this would also mean that the cache doesn't
> depend on excalibur store anymore... 

But:
  * Cache is "This component is responsible for storing and
    retrieving cached responses.", to quote the Javadoc. Store,
    OTOH, can be used by any component to store any data.

  * Cache accepts only CachedResponse. It won't be suitable for
    majority of components.

  * Cache does not have mechanism reacting on low memory (Janitor).

  * Cache has no TRANSIENT / PERSISTENT separation.


We only recently had store clean up (thanks Sylvain) and even not all components 
yet migrated to using stores instead of static HashMaps. I feel it's more 
important to focus on components implementations clean up but not on yet another 
store mechanism re-write.

Vadim


>>The cache is an own component (called Cache) which has 
>>currently one default implementation that uses a Store 
>>(component). Now I think for such use cases a different Cache 
>>implementation is better. This implementation could directly 
>>"cache" the data without going via a store.
>>
>>Carsten