Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Message-ID: <404CD638.7050408@informatik.tu-darmstadt.de>
Date: Mon, 08 Mar 2004 21:23:20 +0100
From: Christian Haul <haul@informatik.tu-darmstadt.de>
User-Agent: Mozilla Thunderbird 0.5 (X11/20040304)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: cvs commit:
 cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl
 CachingSource.java AsyncCachingSource.java RefresherImpl.java
References: <20040306210039.57293.qmail@minotaur.apache.org>
 <404A443E.6010903@hippo.nl> <404B5B58.7020402@informatik.tu-darmstadt.de>
 <404B99F4.8050203@hippo.nl>
In-Reply-To: <404B99F4.8050203@hippo.nl>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

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
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://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.

	Chris.