This proposal needs a lot more information:

• What are the different compression backends proposed, how do they work, and for what types of files?
• What other possible compression backends do you envision in the future? Why were those in the proposal selected specifically for this iteration?
• Your proposal mentions "obfuscation", but I don't see any such functionality in the use case or code skeletons
• Need more use cases, and they need much more detail – include some narrative behind each use case, indicating what the need is, and how the new functionality accomplishes it.

I'm returning this proposal to "New" status. Please get community review prior to requesting recommendation again; I know there are a number of community members who may have opinions on the design and functionality.

I completed this proposal. Code is ready for community alpha testing.
I'm waiting your feedback.

Maxime: the process is quite clear: you need to ask for community review first, and then mark it as ready for recommendation. I've moved it back to "Ready for Review", which is the area for community review. Please post an email to fw-general and/or zf-contributors asking for feedback on the proposal before you mark it as ready for recommendation again.

I have some feedback as well. First, thank you for updating the use cases and code skeletons. However, I still have questions:

• Why is the usage different than other cache adapters? Typically, you attempt to load() from the cache, and then, if it returns boolean false, generate and cache the contents. Your use cases show something quite different.
• Is this intended for inline JS/CSS within your templates, or for caching content for static JS/CSS files? My experience with JS/CSS compressors has been that you usually generate static files within the docroot, but this isn't clear from your use cases or your description of the component.
• From the use cases, it appears you're using output buffering to perform the caching. In most cases, it seems like it would be as easy or easier to simply generate data and save it without the need for ob() functions. Can you indicate why ob is necessary?
• Can you better describe the intended use cases of the component as a narrative in the Overview and/or Theory of Operation sections, please?

It's better to have a component that do js/css compression, and optionaly use Zend_Cache to optimum performance, like Zend_Db_Table store a table description in Zend_Cache, but we don't have Zend_Cache_Db_Table to do this.

Other thing that we don't need to know internal storage of Zend_Cache backends, and you are proposing to use a Zend_Cache struture do to a compression, store a data and to retrieve a diferent data (compressed or minified), I think that cache it's to store and retrieve the same data.

On the other hand, a Zend_Cache_Compression to store some big data to save disk space it's more acceptable, but the compression will slow don't the application.

Integration with Zend_View to automatic join / compress / minifie js and css files are welcome, but it's a hard job to do this, specialy with css.

In my understanding a Cache backend is used internally to store in a wished data structure.
What ever I enter within a cache, I will get the same data when I retrieve it.

It is not intended to get files which can be used external like JS or related.
When I want to compress JS files I would use Zend_Compress / Zend_Filter_Compress / Zend_View or related.

-1 from my side... Zend_Cache is the wrong place for such a feature. I would understand when you want to compress/decompress Cache files but this would only apply to a very small amount of Backends as all binary backends (APC, Memcached) are already compressed.

Thanks for your feedback.
You've right, Zend_Compress should be better. I'll update this wiki page and rename Zend_Cache_Backend_Compress to Zend_Compress.

Thanks for your feedback.
You've right, Zend_Compress should be better. I'll update this wiki page and rename Zend_Cache_Backend_Compress to Zend_Compress.

I'll ask to Steven Brown to help him here : http://framework.zend.com/wiki/display/ZFPROP/Zend_Compress+Proposal+-+Steven+Brown

I have a fully working set of filter components that perform minification on css, javascript, and html. You can see them under the 'ready for review' section of the wiki. I think this proposal would best serve the framework by being refactored as a view helper component that can optionally use existing cache backends for storing the processed output. We should strive to keep caching and minification separate as appropriate to promote the quality and reusability of the zend framework.

Archiving this proposal, feel free to recover it when you want to work on it again. For more details see this email.