[wp-hackers] Caching as part of the core

[Jeff Waugh]

On Wed, Jul 25, 2012 at 4:09 AM, Mike Schinkel <mike at newclarity.net> wrote:

> Page caching could use transients, and pages can be the result of
> composition of fragments.


These really are very separate things.

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.

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.

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).

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).

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.

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 (along with, I would imagine, improvements to widget and theme
APIs to take advantage of it).

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