[wp-hackers] Caching as part of the core

[Almog Baku]

I agree.
The most famous php-application is implement caching as as integral part of
the system.

In drupal for example, there is based cache and you can install a module
who extend this caching.

By the way, drupal - patches to the core is really something unaccepted -
so I really not like this drop-ins idea.. hacky = bad.
If you ask me we should replace this hacky-dropins with much more hooks to
the core, and option to extend it(by using OOP for ex.)

~ Almog

On Wed, Jul 25, 2012 at 2:11 AM, Bryan Petty <bpetty at bluehost.com> wrote:

> On 07/24/2012 12:38 PM, Otto wrote:
> > Page caching would indeed use the advanced-cache.php drop-in.
> > WP-Super-cache does exactly that. Using transients there would be
> > highly difficult, however I'm not sure that you'd want to,
> > realistically. Transients are essentially wrappers around database or
> > object cache calls. Storage of whole-page caching methods is capable
> > of being done more directly, and much faster, without the overhead
> > transients and the object cache bring to the table. Either you store
> > the page cache in a way that bypasses the need for PHP to execute at
> > all (super-cache) or you store the page directly in an external memory
> > system, where the WP_Object_Cache overhead is not helpful to you.
>
> Ok... so now you'll admit that the Transients API has high overhead, is
> difficult to use, and is in-appropriate for page or fragment caching.
> You also admit that the dropins are "hacky as heck".
>
> However, you'll still tell me that's what I should use when I so much as
> suggest that WP_Object_Cache could be expanded (in a 100% backwards
> compatible way) to support persistent cache backends in core like it
> used to, but done the right way this time.
>
> I didn't honestly think I had to actually submit a patch yet just to
> explain what I was proposing since nearly everyone else implements a
> flexible caching system with multiple backends nearly the same way, and
> the way I'm proposing. How about some examples then?
>
> In the category of PHP applications that aren't built on frameworks
> since this is where WordPress falls in:
>
> 1. MediaWiki:
>
> https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=tree;f=includes/objectcache
> 2. phpBB:
> https://github.com/phpbb/phpbb3/tree/develop/phpBB/includes/cache/driver
> 3. Gallery:
>
> https://github.com/gallery/gallery3/tree/master/system/libraries/drivers/Cache
> 4. phpMyAdmin used to use phpExcel's cache library:
>
> https://github.com/PHPOffice/PHPExcel/tree/develop/Classes/PHPExcel/CachedObjectStorage
>
> All of them are mostly designed the same way object cache APIs are
> designed on nearly all the frameworks, let's jump to those:
>
> 4. CakePHP: https://github.com/cakephp/cakephp/tree/master/lib/Cake/Cache
> 5. Symfony: http://www.symfony-project.org/api/1_4/sfCache and
>
> https://github.com/symfony/symfony/tree/master/src/Symfony/Component/HttpKernel/Profiler
> 6. Kohana: https://github.com/kohana/cache/tree/3.2/master/classes/cache
> 7. CodeIgniter:
>
> https://github.com/EllisLab/CodeIgniter/tree/develop/system/libraries/Cache/drivers
>
> (Zend purposely left off the list, but it does multiple persistent
> object cache backends the same way too - just very different frontend)
>
> This isn't even limited to PHP. Even though Python and Ruby web
> application processes handle multiple requests, they still implement
> object cache APIs the same way:
>
> 8. Django:
> https://github.com/django/django/tree/master/django/core/cache/backends
> 9. Beaker (a python cache/session library):
> https://bitbucket.org/bbangert/beaker/src/d1757ad53763/beaker/
> 10. Ruby on Rails:
>
> https://github.com/rails/rails/tree/master/activesupport/lib/active_support/cache
>
> MediaWiki doesn't even tell everyone they should write object cache
> implementations in extensions. They provide over a dozen persistent
> object cache backends to choose from including multiple memcache backends.
>
> How about this...
>
> What if the Transients API was converted over to a WP_Object_Cache
> backend, and used as the default fallback instead of the file backend if
> none of the accelerators are available (APC/XCache/WinCache)? The
> current API can still continue to fire off the same filters (and will
> just make calls into wp_cache_get/set()) and new code can feel fine
> about using wp_cache_get() with an expiration again, and page/fragment
> caching plugins have a persistent object cache to use before the hooks
> system is initialized. The transients API is really just a DB object
> cache backend anyway (but with filters).
>
> --
> Bryan Petty
> WordPress Developer
> bpetty at bluehost.com
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
>