Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <40448764.6080707@hippo.nl>
Date: Tue, 02 Mar 2004 14:08:52 +0100
From: Unico Hommes <unico@hippo.nl>
User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Event caching and CachedSource
References: <40447362.6020001@hippo.nl> <40447E7B.1070008@leverageweb.com>
In-Reply-To: <40447E7B.1070008@leverageweb.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Geoff Howard wrote:

> Unico Hommes wrote:
>
>> Hi gang :-)
>>
>> A drawback I have been running into lately with eventcache mechanism 
>> is that it lacks the ability to remove heavy processing from the 
>> critical path. An event will simply remove a set of cached pipelines 
>> from the cache completely. Making the subsequent request for such a 
>> pipeline potentialy very slow. In applications where isolation is not 
>> a requirement this is an unnecessary drawback.
>
>
>
> Below sounds interesting and good but I haven't understood how event 
> cache is related.  AFAICS the only difference with eventcache and the 
> other validity types is that for the others an invalid response is 
> found in cache, but not used because it is found invalid after 
> retrieval, but the event cache removes the entry at invalidation time 
> since it knows it will never be useful.  Both cases mean that the next 
> person to request that resource will have to wait for the full 
> generation.  Maybe because I've only glanced at the refresher stuff?
>
I guess you are right that at the Cache level nothing really changes. I 
overlooked that fact. I will do some more research on what is required 
to accomplish that in the case of the Refresher, but my idea was that 
the cached response would be served until a newly generated one could 
replace the stale one. Since the Refresher talks to the Cache directly, 
given the correct Validity strategy it can exercise full control over it.

> Bottom line for me at moment is: do you foresee a need to modify the 
> eventcache API to accomodate this need?  I'm getting ready to start a 
> discussion on changing the eventcache unstable status -- should I hold 
> off?
>
I don't think my current work will influence the eventcache API 
directly. Although I am not sure if
the eventcache stuff can be considered stable enough. I still have some 
doubts about the ease of use of parts of it especially the way events 
are associated with cached objects. But lets discuss that separately.

>> I am looking at the excellent CachedSource stuff that is in the 
>> scratchpad area ATM and am wondering how it fits together with the 
>> eventcache stuff. One thing I am looking into right now is to write 
>> an EventAware Refresher implementation.
>>
>> For those unfamiliar with CachedSource, it is a Source wrapper that 
>> can cache a its delegate. Refreshing can be done either synchronously 
>> or asynchronously but currently only based upon a specified time-out. 
>> What I'd like to do is generalize this a bit in order to add the 
>> ability to  externally trigger invalidation.
>>
>> For this however I think a modification to the Refresher interface is 
>> needed.
>
>
>
> BTW, how does CachedSource accomplish something different from the 
> caching point pipeline (which seems to accomplish more, though I've 
> never used it).
>
I never used it either. So I really don't know. Perhaps someone else 
could comment on this?

Cheers,
Unico