Christian Haul wrote:
Unico Hommes wrote:
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?
Say, you would like to access you webdav always asynchronously as well as remote webservices. Local services, however, should be accessed
directly.
Solution 1 is to go through your sitemap and wrap your URLs accordingly. Solution 2 is to say, for "http://*.localsite.com/*"; use plain http, for everything else use "acached://[EMAIL PROTECTED]" (or a better syntax that doesn't encode everything into the URL).
To achieve this, one could replace the component selector holding the source factories and always return a wrapper. Only when the real URL is available (eg absolutize() or get() is called), the decision is made which factory to use.
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.
Ah well. I have Documentum DQL as URL and would need to have something else for a key, like the document ID or a folder name.
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.
But AFAIK there's either "do now", "do at cron spec" (like mondays at 12am), or "do every x minutes starting in x minutes". Of course, what
I would like to have is just a combination of addPeriodicJob() and fireJob() ....
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.
Makes sense.
Chris.
