[wp-hackers] Caching as part of the core

[Almog Baku]

Guys, if you say that we can't force the users to use one method.. We have
to delete the tinyMCE and jQuery.

All long the way there are decisions we should take. As jQuery chosen
against dojo and extjs..
So, its a rediculus argument.

Caching is something WE NEED.
Official API is something WE NEED.
HACKING of the socre is something we NOT need.

בתאריך יום ראשון, 29 ביולי 2012, Bryan Petty כתב:

> On 07/28/2012 08:38 PM, Jeff Waugh wrote:
> > On Sun, Jul 29, 2012 at 11:16 AM, Bryan Petty <bpetty at bluehost.com<javascript:;>>
> wrote:
> >
> >> When every plugin of a fairly generic type (in this case, page caching)
> >> requires the installation of the same plugins (APC/memcache), that gives
> >> off a "smell" like the core WP API is lacking adequate support for
> >> something it should already have.
> >>
> >
> > Not every page caching plugin needs wp-content/object-cache.php, but
> it's a
> > handy way to share code. Particularly if it's as well-written and
> > widely-trusted as the Memcache and APC drop-ins.
> >
> > Batcache requires a persistent object cache implementation (:161-166). It
> > once used memcache directly.
> >
> > WP Super Cache will load a persistent object cache implementation and
> > optionally use it (experimental feature according to the admin pages).
> >
> > W3 Total Cache, being... special... does its own thing, has multiple
> > backends, etc.
> >
> > This doesn't seem like a bad state of affairs to me.
>
> Really? You don't think it's bad that just among the plugins named here,
> there's 2 file backends, 2 APC backends, 2 memcache backends, and 3
> other backends already?
>
> Let's add a few more and see where the totals are at:
> - Fast Full Page Cache (apc, memcache, memcached)
> - Tribe Object Cache (apc, memcache, wincache, xcache)
> - FlexiCache (memcache, db, file)
> - Cachify (apc, db, file)
> - WP Widget Cache (file)
> - WP Green Cache (file)
> And for good measure, the rest of the object cache only plugins:
> - Memcached Redux
> - WinCache Object Cache Backend
> - XCache Object Cache Backend
> - WP File Cache
> - DB Cache Reloaded (and a forked plugin just as popular)
>
> Totals:
> - memcache(d): 7 (or 8 if you count Batcache's old one)
> - apc: 5
> - file: 7
> - db: 4 (or 5 if you count transients)
> - wincache: 3
> - xcache: 3
> - eaccelerator: 1
>
> So I count a grand total of over 30 unique object cache backends just in
> the plugins I can find in the directory, and they still only cover
> exactly 7 unique storage methods (or 8 if you identify memcache from
> memcached).
>
> I wouldn't call that sharing. Batcache is the only page caching plugin
> that doesn't include it's own additional backends.
>
> > Surely before you
> > adopt application-level page caching, you're going to use a persistent
> > object cache, and you'll configure your system to use it appropriately.
> > Then, should you choose a page cache designed for key/val style storage,
> > it'll automagically use the implementation you've chosen. No more
> > integration to do, benefit of shared code, etc.
>
> This is exactly what I'm pushing for. The only difference is that these
> persistent cache backends are actually built into WP core, so in
> addition to everything you mention here, every admin knows that there's
> always one guaranteed way to configure it (and in most cases, they won't
> have to because it can be auto-detected and auto-configured for them),
> and everyone truly actually shares the same code that implements every
> backend (if they want to anyway, they still wouldn't be forced to just
> like they aren't now).
>
> --
> Bryan Petty
> WordPress Developer
> bpetty at bluehost.com <javascript:;>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com <javascript:;>
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>