[wp-hackers] Caching as part of the core

[Mike Schinkel]

On Jul 28, 2012, at 8:00 PM, Jeff Waugh wrote:
> I have read the entire thread. Your replies continue to suggest that you
> don't understand what advanced-cache.php is for, or how it's used.

Maybe, but it doesn't seem to be the case based on your choice of aspects to debate. And this discussion has become perverted and doesn't resemble how it started. 

It was started by someone who asked for caching in the core[1] to which he received a shit-storm of replies[2,3, 4 & more] that effectively told him he was stupid for asking.  Someone else suggested that a cache API was need and to enhance the use of transients[5]. I latched onto that and called for a focus on a cache API in core vs. caching in the core, per se[6], I made a comment that Transients could *potentially* be used for persistent storage, and I later proposed hookable dropins[8].  Since then, the discussion has devolved significantly to where it is now.

[1] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043701.html
[2] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043703.html
[3] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043738.html
[4] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043729.html
[5] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043707.html
[6] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043720.html
[7] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043801.html
[8] http://lists.automattic.com/pipermail/wp-hackers/2012-July/043772.html

> I hope this makes it obvious why transients (and similar higher level
> caching mechanisms) simply aren't relevant when it comes to page caching.

After my last message and before going to sleep I implemented the code to support hookable dropins and created a trac ticket:

http://core.trac.wordpress.org/ticket/21412

This IMO works extremely well.  It's very lightweight and as far as I can tell would have no nasty side-effects.

I also tried to make Transients work and discovered that, as you say in your reply, they bring in too much baggage.   So part of the minor premise from my posts listed above failed, which is that Transients could be reused for page fragment caching at the point advanced-cache.php is loaded.  I was wrong, but that wasn't the major premise.

But the major premise is that we need a (set of) caching API(s) in core, and changes to enable it.  The hookable dropins ticket is one such change, and the fact that Transients don't work better validates that a purpose built API is needed for caching. I think one of the next steps is deterministic method of identifying fragments which I'll call a "fragment query" to compare it to the query used by WP_Query.

But I don't have time to work on this now.  I have other things I've like to work on in hopes of contributing to 3.5.

> There you go. Evidence. Data. *jazzhands*

> Walking through the core code, and the common caching-related plugins, only
> reaffirms my support for the current approach. It turns out that clever
> people have had quite a bit of time and paid attention to make good
> decisions about this stuff. :-)

One final question.  What's your dog in this hunt?  

Both Bryan and I are advocating for a change, hence our reason to debate on the list. On your side you are effectively saying both of us don't get it.  If we are really wrong then nothing is going to change in WordPress from our discussions.  

So why spend time debating us? Why spend part of your days where you could be doing something else but instead come here and tell us how wrong we are? If you are right, nothing will come of our comments here on the list even if you didn't debate us, right? Does duty call?

-Mike