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.
>
> 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.
>
> Instead of:
>
> Refresher {
> refresh(key,uri,timeout);
> periodicallyRefresh(key,uri,timeout);
> }
>
> I'd like to remove timeout semantics from the interface:
>
> Refresher {
> refresh(key,uri,params);
> }
>
> I don't think there is currently a reason for there being two
> the separate methods. So I think we can safely combine them
> into one. But I guess I am looking at Carsten for confirmation... :-)
>
Although you actually don't need my confirmation as it's not my
but *our* source, here it is :)
I think this makes sense and I think we should also move this
out of the scratchpad afterwards as well.
Carsten
