TYPO3 Core

The wiki tells us to define a 'frontend' in our caching framework configuration:

$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_myext_mycache'] = array(
    'frontend' => 't3lib_cache_frontend_StringFrontend',
    'backend' => 't3lib_cache_backend_DbBackend',
    'options' => array(
        'cacheTable' => 'tx_myext_mycache',
        'tagsTable' => 'tx_myext_mycache_tags',
    ),
);

And an article by Dmitry does not:

$TYPO3_CONF_VARS['SYS']['caching']['cacheConfigurations']['cache_myext_mycache'] = array(
    'backend' => 't3lib_cache_backend_DbBackend',
    'options' => array(
        'cacheTable' => 'tx_myext_mycache',
        'tagsTable' => 'tx_myext_mycache_tags',
    ),
);

Dmitry is right here and here is why:

An integrator is asked to configure the caching framework of an extension s/he installs. S/he has to know the backend s/he wants to use, it may be DB, memcached, ... and as such defining the 'backend' is correct. BUT the frontend defines what is stored within the cache backend, the "format" of the input that will be cached. The integrator should not have to dig into the code to know the format, this is the responsibility of the developer that should simply instantiate the frontend with the format he needs. It could be clever and still let the integrator choose another frontend (for whatever reason) but forcing the integrator to define the frontend (even if it's copy/paste from the extension documentation how to activate/configure the caching framework), does not make sense.

Problem is shown, e.g., when invoking scheduler task "Caching framework garbage collection (scheduler)". If a caching configuration is incomplete for a given extension (missing 'frontend'), the task will crash with:

Execution of task "Caching framework garbage collection (scheduler)" failed with the following message: Class does not exist

as an empty class name is passed to t3lib_div::makeInstance() and this throws an error when trying to instantiate this "class" by reflection.