Hiya, I'm probably wrong here, but my understanding of the RefresherImpl is that the "timeout" is used to cache the page on a timed basis a la cron (although that could be what you mean).
I'm not entirely sure how this helps with external validation directly :) What I've been playing around with in this class is a "refreshInFuture" method which does a one-time-only refresh in x seconds (probably 1 minimum to be safe from expiry problems :) Does that help you at all? I'm happy to contribute it if it would. Corin -----Original Message----- From: Unico Hommes [mailto:[EMAIL PROTECTED] Sent: Wednesday, 3 March 2004 12:44 a.m. To: [EMAIL PROTECTED] Subject: Event caching and CachedSource 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... :-) Cheers, Unico ================================================================ CAUTION: This e-mail and any attachment(s) contains information that is intended to be read only by the named recipient(s). It may contain information that is confidential, proprietary or the subject of legal privilege. This information is not to be used by any other person and/or organisation. If you are not the intended recipient, please advise us immediately and delete this e-mail from your system. Do not use any information contained in it. ================================================================ For more information on the Television New Zealand Group, visit us online at http://www.tvnz.co.nz ================================================================
