The spec of Legacy_Controller cache mechanism (1)

Legacy_Controller is heavier than XOOPS2 JP, because XOOPS Cube defines more classes. Therefore, powerful cache mechanism is important for us. Powerful cache often raises problems. For example, if a cache file is made by an access of the administrator, anonymous users and registered users may see secret informations. Also, anonymous users should not be able to see the cache which is made by an access of registered users.

More problems. XOOPS2 JP makes cache files irrationally for any URL. For un-existed ID and difference URLs which express the same data, XOOPS2 JP makes each cache files, because common.php in XOOPS2 JP can't connect with a module to get the cache policy of modules. If XOOPS2 JP modules have a sub-class of the module class, we may add some new methods to the base class for the controller. But, XOOPS2 JP doesn't have such concept. common.php doesn't load module files except of xoops_version.php. And, xoops_version.php doesn't have the spec about the cache. No modules have defined them. Therefore, we may use definitions of xoops_version.php as optional, but Legacy_Controller should not depend on such definitions. In addition, many site owners want to tune up the strategy of the cache, so we should consider it.

For these situations, we should choose XCube_Delegate to enable to implement an exchangable cache mechanism. It's clear what informations Legacy_Controller wants to get from modules. So we'll add new methods to Legacy_Controller, then exchange these functions as Delegate. And, the standard cache module should offer default functions to the delegate.

Also, the means to clear existed cache file, is important.