[wp-hackers] Caching as part of the core

[Almog Baku]

I think that the core should offer base fragment caching, or at least
prepering interface for it.
So.. I offer two options for implementing:

   1. Implemet the fragment caching as a part of the core.
   2. Adding only option for interface at the api. so the data will saved
   and will implements by 3rd party plugins.
   In any case- adding this data parameter inside the core and the docs
   will force the developers to notice and be known to the caching issue.
   *
   Why we need that?*
   Because it let us better caching comptability with the plugins and
   themes.


On Tue, Jul 24, 2012 at 8:25 PM, Otto <otto at ottodestruct.com> wrote:

> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>