Re: Re: API's was Benchmarks

> > 2 Cache classes > > I think this, with some minor tweaks, could actually become a rolemodel > for the future I wish to precise that Cache_Lite is not only a restriction of the Cache API. Some features are included in Cache_Lite (like anti-corruption systems...) and not in Cache. But the API is very flexible because of the use of associative arrays for the main configuration for example. On the meeting summary, I read : [[[ A "light" implementation of a package needs to be extended to provide a richer set of features. Example cache_lite would have to extend cache, i.e. "cache API extends cache_lite API". ]]] Why not but which class has to be modified to respect this idea ? The classic one or the light one. IMHO, the choosen API has to be very flexible (associative arrays for main configuration...) because if API are synchronized with a "not flexible" one, you can't add a feature on one package without breaking the API compatibility ! In this case, packages are tied. Just my opinion :) Fabien