[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/25/2012 12:33 AM, Otto wrote:
> We consider that plugins are first-class citizens in the WordPress
> world. Most of the code in core *is* a plugin. It's all implemented in
> the same way. Actions and filters, my man. Actions and filters.

You don't just move everything to a plugin because it *can* be one. You
wouldn't strip out the admin settings panel or the reserved Pages CPT
and toss it in a plugin even though both could be. But, it makes perfect
sense that importers are plugins, and it also makes perfect sense that
the links are being moved to a plugin.

There's obviously a level of what functionality you should ship by
default with the core application that both plugin developers and users
can rely on and expect that every WP installation has those features and
functionality. Also, you said it yourself, the 80/20 rule.

> You haven't explained your concept well-enough to convince me of your
> correctness. You say "it was proven that developers obviously need to
> be taught how to use a file cache backend appropriately", but you
> didn't give any technical detail. Please, enlighten us. What is the
> appropriate way? This is wp-hackers, we can take the technical detail.

Sure, you show me which code was using wp_cache_get() back when it was
file-backed that was triggering it to create thousands of files and read
back at least a dozen of them per request, and I'll show you what they
did wrong, and how to fix it. It's very easy to fix.

I *am* telling you how the object cache can be fixed without running
into this problem again, and I *did* give you technical details on how I
would re-design the object cache so it doesn't run into those
limitations. All you had to say without being condescending, was "What
were they doing wrong?"

What they were doing wrong was either using too much granularity for the
data they were caching, or if it really didn't need to persist across
connections, they could have simply stored their own cache data in a
static variable themselves. WordPress made the call that no-one's
wp_cache_set() calls needed to persist when it removed the file-backed
cache, moving *everyone's* cache to a static variable for them
regardless of whether it was the cause of the problems or not and
regardless of whether that cached data really did need to be persistent
to be effective.

Maybe developers just weren't warned enough that it was a file-backed
cache they were saving to in the docs for the object cache methods and
what that meant for how they should use it, but it wasn't the design of
the cache that was at fault. There's a chance it could have been more
efficient itself. But it had a purpose, and it's purpose was to provide
a persistent object cache, not to just be an object cache, that's what
variables are for.

> I remain unconvinced.

That's fine. I've explained it, and I've answered your questions.
There's nothing more I can really do. You're insistent in being stubborn
about it and not being open to solutions, and that's your right. It's my
right to not care if you still don't understand it.

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com