[wp-hackers] Caching as part of the core

[Mike Schinkel]

On Jul 28, 2012, at 2:01 AM, Jeff Waugh wrote:
>> Page caching could use transients, and pages can be the result of
>> composition of fragments.
> 
> These really are very separate things.

Yes. As was stated...

> Page caching is too low level to bother about transients or fragments, and
> you're always going to use transients or fragments in the higher level,
> application logic context of a plugin or theme. That's where they make
> sense.

I disagree with that, and I don't see any evidence to the contrary.

> You want to get in and out of advanced-cache.php as quickly as possible --
> if at all. The call tree is tiny: wp-config.php -> wp-settings.php (very
> few files loaded, actions taken prior to...) ->
> wp-content/advanced-cache.php.

Agreed, with the operative phrase being "as possible."  As quickly as possible, but no quicker.  Such as when you need to compose a page from a cached page template merged with fragments.

BTW, Transients are but one potential metho of storing fragments. I mentioned it because it is an API that exists that other people have pointed to as a solution even though it actually can't be used in /wp-content/advanced-cache.php.  I'm simply saying "make it work in  /wp-content/advanced-cache.php." 

> If the advanced-cache implementation in use wants to use the provided
> object-cache implementation, rock and roll -- it can load it itself (as
> wp-super-cache does).

I just scanned the code in WP Super Cache and what you said is not true; WP Super Cache does not load the provided object-cache implementation, which is in /wp-includes/cache.php.  

Yes WP Super Cache's /wp-content/advanced-cache.php does call /wp-content/object-cache.php, but the latter is also a dropin so you are proposing to solve the problem I identified with a solution that has the same problematic attributes of the problem identified.   

> Themes and plugins can already use transients or the object cache API to
> cache fragments, while providing their own cache invalidation logic (or in
> the case of transients, timeouts).

Yes but that's irrelevant.  Themes and plugins can't use the existing Transients or object cache API in /wp-content/advanced-cache.php if there is any chance they won't be able to serve the content and thus must continue loading WordPress.  WordPress does a require(' /wp-includes/cache.php') after it calls /wp-content/advanced-cache.php so attempting to load them twice will result in an error. 

> A fragment caching API in core would have to consider the many and varied
> use cases for fragment caching *and* the many and varied strategies for
> cache invalidation.

No it wouldn't.  It would need only provide a useful implementation that covers 20% of the common patterns used 80% of the time, and then be hookable so that it can be extended for the many and varied use-cases for for fragment caching *and* the many and varied strategies for cache invalidation.

BTW, I've heard caching has too many variables but I've yet to see anyone give real world use-cases to demonstrate that there are actually too many methods and too varied of strategies.  It may be the case, but I've not seen any evidence to back up those claims.  Show me how it "can't" be done and I'll likely uncover the underly pattern that would enable it to be done.
 
> If you make a kickarse fragment caching API in the form of a plugin, and it
> solves lots of problems and excites lots of developers, it may just make it
> into core.

Can't write a kickarse fragment caching API in the form of a plugin.  See below as to why.

> But there's no sense arguing hypotheticals without code. :-)

Then why did you decide to argue it hypothetically?  And why the religion on this issue? Why get so charged up to defend core against caching yet ignore the specifics needed to enable code to be written?

I'll repeat a 3rd time the things I previously asked for on this thread  (which nobody has yet acknowledged, btw) so that a kickarse caching API *could* be implemented:

1.) Load the Transients API before advanced-cache.php is called[1]
2.) Enable multiple dropin files per type of dropin and enable hooks before advanced-cache.php[2]
3.) Address this fragment caching ticket[3] 

So can we focus on these issues instead of hypotheticals?

-Mike

[1] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043801.html
[2] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043772.html
[3] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043792.html