"J.H." [off-list ref] writes:
While I don't disagree, being able to support other caching systems
would be nice, we have this now, it's tested and it works. I'd argue
this is a step 1, step 2 case at this point.
I would have to agree; getting some cache layer that is known to work (you
are battle testing your updates on a busy site of yours as you develop,
right?) early, quick and dirty with minimum changes, is more beneficial
than waiting for a large rewrite thats "gets it perfect this time".
I'm currently working from on top of Jakub's last tree, though I've got
some questions about his reasoning on a few things now that I've been
digging into it.
Thanks both for keeping the ball rolling.
On Wed, 24 Nov 2010, Junio C Hamano wrote:
"J.H." [off-list ref] writes:
quoted
While I don't disagree, being able to support other caching systems
would be nice, we have this now, it's tested and it works. I'd argue
this is a step 1, step 2 case at this point.
I would have to agree; getting some cache layer that is known to work (you
are battle testing your updates on a busy site of yours as you develop,
right?) early, quick and dirty with minimum changes, is more beneficial
than waiting for a large rewrite thats "gets it perfect this time".
I also agree, that's why I'd like to go the "minimal fixups" route, where
those minimal fixups are about caching being robust (loading cache.pl,
passing minimal tests), not penalizing non-cached case (moving check for
$caching_enabled out of cache_fetch), and make it possible to move to
better solution / other caching engines in the future while maintaining
backward copmatibility (configuration is API; $caching_enabled, perhaps
also $cache (is 'cache.pl') and %cache_options).
quoted
I'm currently working from on top of Jakub's last tree, though I've got
some questions about his reasoning on a few things now that I've been
digging into it.
Thanks both for keeping the ball rolling.
--
Jakub Narebski
Poland