cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Haul <>
Subject Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl
Date Mon, 08 Mar 2004 20:23:20 GMT
Unico Hommes wrote:
> 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

Solution 1 is to go through your sitemap and wrap your URLs accordingly.
Solution 2 is to say, for "http://**" use plain http, for
everything else use "acached://600@{0}" (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.


View raw message