[wp-hackers] Caching as part of the core

[Otto]

On Tue, Jul 24, 2012 at 11:38 AM, Almog Baku <almog.baku at gmail.com> wrote:
> I asked what about the adding the cache to the API as option to the basic
> hooks as I suggest before:

Yeah, I read that before. Three times. But I didn't understand it.

Again, compression and concatenation have nothing to do with "caching"
at all. So why you're even bringing them up, I have no idea.

Also, you're giving interface examples, but you're not explaining what
any of it actually does or how it magically would make anything
faster. Adding a "cache" parameter to a register_post_type call
doesn't make any sense, for example. You didn't specify what exactly
is being cached, how, or why there.

Fragment caching for things like sidebars could be done for cases
where it is beneficial, but it's not something that makes any sense
for the core to do, and certainly not with the proposed interface.
Dynamic sidebars are made of widgets, caching them in the database or
to a filesystem would actually probably make things much slower, and
putting them in the object cache would make them more static and
non-dynamic, which is fine for high-traffic sites, but undesirable on
the majority of sites.

There is no one-size-fits-all solution to caching, and doing heavy
modification of various pieces to add things like this makes no real
sense. It makes more sense to implement them as plugins, to give
websites the freedom to choose and implement their solutions in their
own ways. If one solution becomes extremely popular, then it makes
sense to start talking about core support for it, but the fact is that
most sites don't *need* caching and would not benefit from it. It
doesn't fit the 80/20 rule.

The core support object caching extensively, and in complex and useful
ways. If you want to achieve massive benefits, install an external
object caching plugin and use it. I use W3 Total Cache myself for that
exact purpose. It's awesome. But it's certainly not for everybody, nor
are we there yet.

-Otto