[wp-hackers] Caching as part of the core

[Bryan Petty]

On 07/24/2012 10:06 PM, Otto wrote:
> No, I tell you that it's appropriate to implement persistent cache
> backends *for your specific needs*. It shouldn't be in core. It should
> be done on a per-host, per-server, per-setup basis.

If this were true, there wouldn't even be an object cache in core at all
but there really is only one single way an object cache can be
"customized" per-host/per-server/per-setup, and that's simply just
selecting the appropriate backend based on what's available. I really
don't feel like you should be required to go through the trouble of
installing a 3rd party plugin just to choose the backend you're going to
use for that site (unless it really is using some obscure backend that
no-one has heard of - but the advanced-cache.php dropin could still be
used for that).

Beyond that, it's an object cache, and the frontend API is exactly the
same for all of them, only one of them doesn't support expirations. Why
do you suppose WP already has that API and a default backend implemented
in core?

Your argument here might be helped a little though if the automated
plugin installer also supported automatically moving any dropins
contained in a plugin to wp-content. That still has to be done by hand
on all installations. Even if that was automated though, it still
wouldn't change my opinion here.

> There's no universal answers here. Core can't implement persistent
> caching in a universal way that doesn't have downsides.

I'm saying it can, but yes, we can leave it at that and maybe some day
soon I will show you.

> Implementing the object, or the transients, cache as a file backend is
> a *proven* loser. It sucks. Royally. On the majority of hosts. Search
> for the arguments over 5 years ago to find proof.

Well, it was proven that developers obviously need to be taught how to
use a file cache backend appropriately, but did you fully understand
what that last suggestion I made was? Under that, neither the object
cache or the transients API would actually use the file backend by
default (only if the site admin explicitly configured it to... maybe
they don't want it or can't have it writing to the DB for persistent
objects but still don't have access to accelerators or memcache).

> This is open source. You don't get anywhere without code that actually
> gets the job done, man.

Yep, I'm very aware of that. You must have missed my introduction to the
list last month when I mentioned being a core developer on another
widely popular open source project, and being involved with the Google
Summer of Code program for 3 years as a mentor.

Anyway, I never start on any medium to large project like this on an
important component without getting some feedback from the community
first, and seeing how the dev team that will ultimately be reviewing it
feels about how I plan to write it. That's all this is right now.

If the community has strong convictions against it, I'm not going to
write it. I'm not doing this for my own WordPress sites, I'm doing this
for the best of the project (and this truly is something that would
benefit everyone). I actually still wouldn't do it on my own sites if
it's not going to make it in core either since it would be a
modification to core code that I would have to re-apply and maintain on
each site with every upgrade.

-- 
Bryan Petty
WordPress Developer
bpetty at bluehost.com