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?
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
--------------------------------------------------------------------
