cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: cvs commit: cocoon-2.1/src/blocks/scratchpad/java/org/apache/cocoon/components/source/impl CachingSource.java AsyncCachingSource.java RefresherImpl.java
Date Sun, 07 Mar 2004 21:53:56 GMT


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


Mime
View raw message