Christian Haul wrote:
Unico Hommes wrote:
:-( I had so many changes on my local FS for these classes. I totally reworked their implemenatations. Not your fault though. I should have worked more incrementally and checked them in sooner. I'll find a way to merge it all.
Well, I wouldn't mind if you just dump my changes. As the message said, I was just moving things around for documentation purposes, really. (Some prefer comments, some prefer speaking names for rather small methods)
Just to give you an idea of what I am doing here is a quick summary:
Basically I want to move all communication with the Cache into the Refresher. I am renaming RefresherImpl to DelayRefresher and adding a Refresher implementation that is externally triggered by events. I am changing the location protocol string as discussed earlier. Probably can merge CachingSource and AsynchCachingSource.
This sound really cool and actually, I was planning for something similar :-)
However, I'm not quite sure if this is the way to go. I'm currently thinking of intercepting and wrapping sources at the selector level.
With the current setup, we need to add the configuration to the URL in all places it is used. By wrapping a protocol with a cached version we wouldn't be able to distinguish eg access to a local services from a remote service (in terms of network hops).
So what if we were to intercept those sources at the selector based on eg wildcard matching on URL? This would be "cross-cutting" and it would be easy to provide more complex caching parameters for a wrapped source.
For the life of me I can't figure out what exactly it is you are saying. Care to elaborate? Perhaps give an example?
Esp. with a event based cache, how would you specify the event to invalidate the source from within the URL?
I was thinking to use querystring parameter to pass it in and default to the wrapped Source's system id (getURI). This is what I am using right now for WebDAV sources and it works perfectly.
I also changed the way DelayRefresher persists its entry configurations to instead of doing a manual xml serialization of the data just dump the whole Map of entries into a persistent store.
Cool.
By the way I think you are the one to ask Christian: I noticed there is no scheduler.addPeriodicJob(.. Object job, ..) method. Is there a reason for this or can I add one? So that the Refresher can add itself and its update targets directly.
Although I'd like to help I haven't touched the Cron block before. But speaking of addPeriodicJob() it would be great to have a way to say "do this right now AND repeat every 10 minutes". The current implementation
provides only for a "do this every 10 minutes and start in 10 minutes for the first time". IIUC this limitation does not stem from the Qartz API but from what the Cocoon JobScheduler provides.
Yeah it does. There already exists a plain addJob method with the signature I am talking about.
Speaking of random ideas around the cached source, it might be nice to provide a URL for the content when it's not yet available. But then this might add too much features to a supposed to be simple concept.
I was also thinking of an implementation of the update mechanism where objects don't get invalidated if they cannot be regenerated (eg. due to WebDAV server offline, network problems, etc.) but get rescheduled instead.
Sorry for messing your stuff up. I'm very excited to see what you have done.
No problem. I expect to check in some of my work later this week.
-- Unico
