> Vadim Gritsenko wrote:
> > 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.
>
> sounds easier than Ard's proposal (no offense ;-) ), or do I
> overlook something?
That certainly is a *lot* easier and I was not aware of this part in the
cachingsource! Might be useful for me as well :-)
Ard
>
> >> 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?
>
> either it comes through a transitive dependency or I did
> something wrong with my
> setup. I will check where it comes from.
>
> >> 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.
>
> It would be great if you could help me with the design of the
> refactoring: If
> you did it, into which parts would you split it up?
>
> --
> Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
>
> {Software Engineering, Open Source, Web Applications, Apache Cocoon}
>
> web(log): http://www.poetz.cc
> --------------------------------------------------------------------
>
