Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (herse.apache.org: local policy)
Message-ID: <4607EE4C.9090604@reverycodes.com>
Date: Mon, 26 Mar 2007 12:01:16 -0400
From: Vadim Gritsenko <vadim@reverycodes.com>
User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Moving reduced version of CachingSource to core | Configuration
 issues
References: <4607B259.6010505@apache.org>
In-Reply-To: <4607B259.6010505@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Oops, should have read it in full...

Reinhard Poetz wrote:

> I can think of setting the expires parameter to -1 and using a
> background-refresher but this seems to be overly complex for this simple task.

Yes async will do the trick. And IMHO it should be Ok to alter sync 
implementation to keep previous response if new one can't be obtained.


> I would also like to move the basic functionality of the CachingSource 
> into some core module and only have an extended versions (event-cache 
> support, async updating) of it in the reposistory block. I seems odd to 
> me that I have to add a dependency to the repository block, the 
> event-cache block, the jms block and the cron block

I do not think it has any dependencies on cron, where do you see it?


> just for this. Any comments before I start a vote on this?

Async is a basic functionality which must be in core, IMHO. But I completely 
agree that event-cache and jms should be optional. I was planning on doing this 
refactoring but did not manage to do it so far.

Vadim