Kip Hampton wrote:
I think that, after looking more closely still (too closely probably),
regenerating dynamic but unchanged content can be avoided as long as 1)
we limit the calls to Provider::process() to only the places where the
Provider is known to need to provide new content (e.g. where ev
Matt Sergeant wrote:
On Thu, 13 Mar 2003, Kip Hampton wrote:
So I'm happy for you to do whatever is required as long as it doesn't
break regular file use.
Agreed.
Plus you can probably use the current AxKit::Cache
module for doing provider level caching.
Yup, any other way would silly and wrong,
On Thu, 13 Mar 2003, Kip Hampton wrote:
> Given this, I think that to cover the cases I'm trying to address, the
> *Provider* has to maintain its own content cache, then decide within
> itself whether to offer the cached copy of a resource or to reprocess to
> generate new content-- any other solu
Jörg Walter wrote:
On Thursday, 13. March 2003 22:53, Kip Hampton wrote:
Howdy AxDevers...
I think I've stumbled over a subtle logic flaw in AxKit.pm's
main_handler method as it relates to Providers and caching. The
"problem" lies in the fact that the Provider's process() method is
called before de
On Thursday, 13. March 2003 22:53, Kip Hampton wrote:
> Howdy AxDevers...
>
> I think I've stumbled over a subtle logic flaw in AxKit.pm's
> main_handler method as it relates to Providers and caching. The
> "problem" lies in the fact that the Provider's process() method is
> called before determini
