Skip to end of metadata
Go to start of metadata

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

<ac:macro ac:name="unmigrated-inline-wiki-markup"><ac:plain-text-body><![CDATA[

Zend Framework: Zend_Filter_Compress Component Proposal

Proposed Component Name Zend_Filter_Compress
Developer Notes
Proposers Thomas Weidner
Zend Liaison Matthew Weier O'Phinney
Revision 1.0 - 16 January 2009: Initial Draft (wiki revision: 11)

Table of Contents

1. Overview

Zend_Filter_Compress is an filter extension for Zend_File_Transfer and allows to compress and decompress files.

2. References

3. Component Requirements, Constraints, and Acceptance Criteria

  • This component will compress files
  • This component will decompress files
  • This component will support Adapters for the handling of different compression formats
  • This component will not support stream compression/decompression
  • This component will only support files

4. Dependencies on Other Framework Components

  • Zend_Exception
  • Zend_Filter

5. Theory of Operation

The Zend_Filter_Compress extension allows to compress and decompress files by using the filter interface. With this component Zend_File_Transfer and also Zend_Form_Element_File are able to allow compression/decompression of files at upload and download progress.The component is instantiated with a mind-link that ...
It is built upon adapters and can easily be extended. Each adapter supports one PHP extension or compression format.
All known php extensions for compression formats will be supported.

6. Milestones / Tasks

  • Milestone 1: [DONE] Proposal finished
  • Milestone 2: [DONE] Proposal accepted
  • Milestone 3: [DONE] Integration
  • Milestone 4: [DONE] Unittests
  • Milestone 5: [DONE] Documentation
  • Milestone 6: [DONE] Move to core

7. Class Index

  • Zend_Filter_Compress
  • Zend_Filter_Compress_Interface
  • Zend_Filter_Compress_Bzip2
  • Zend_Filter_Compress_Lzf
  • Zend_Filter_Compress_Rar
  • Zend_Filter_Compress_Zip
  • Zend_Filter_Compress_Zlib
  • Zend_Filter_Decompress

8. Use Cases


Manual compression


Manual decompression


Compression and store it under a new filename


Using Zend_File_Transfer with compression


Using Zend_Form_Element_File with compression

9. Class Skeletons



Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.
  1. Jan 16, 2009

    <p>Looks good.</p>

  2. Jan 16, 2009

    <p>Is there that much value in having Compress have compress() and decompress(), and having an interface? Seems like it would be easier to just put the implementation into Zend_Filter_Compress_Zlib::filter() and Zend_Filter_Decompress_Zlib::filter(), for example.</p>

    1. Jan 16, 2009

      <p>First: Configurability / Usability / Simplicity</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      new Zend_Compress(array('format' => 'Rar', 'chunk' => '1MB'));
      <p>is better than</p>
      <ac:macro ac:name="code"><ac:plain-text-body><![CDATA[
      new Zend_Compress_Rar(array('chunk' => '1MB'));
      <p>as you could change the used adapter within your configuration. When you make a failure in your config, the second would throw a "class xxxx unknown" where the first would return "compression extension xxx unknown".</p>

      <p>Second: Code reduction<br />
      As Compress and Decompression are mostly using the same functionality (only one line difference) it would not be good to duplicate the code. Otherwise the first would be dependent on the second.<br />
      Useless in my eyes. <ac:emoticon ac:name="smile" /></p>

      <p>Note that these classes are adapters and there is an abstract class/interface.<br />
      And by using a generic entrypoint we make it possible to add own filter adapters in future.</p>

      <p>Adapters are used often in ZF. Using adapters makes it also possible to downgrade to a, possibly in future implemented, Zend_Compress component instead of writing a own new filter.</p>

      <p>For consistency we would then also have to change the encryption filters and divide them into a "encrypt" and a "decrypt" tree of classes when we also divide the compress filter tree.</p>

      <p>I would like to have a reduced amount of classes/files when possible, as in this case.</p>

      <p>Third: Automatism<br />
      Using a base class Zend_Filter_Decompress makes it possible to add a way to detect which compression is used and call the proper adapter for decompression.</p>

      <p>Using fixed classes would mean that there is no way for detection and you only get an exception and have to try all adapters once until one can act without failure.</p>

  3. Jan 21, 2009

    <p>It would be nice if this component can create folders in archives , adding more files , now it have very limited functionality (look <a class="external-link" href=""></a> )</p>

    1. Jan 21, 2009

      <p>This is not a component, it's an additional filter to add support to the existing Zend_File_Transfer component.</p>

      <p>What each adapter will support is not defined within this proposal because it depends on the used extension. Some of them do not provide multiple archives, nor the creation of folders within archives.</p>

      <p>Therefor the creation of folders in archives will not be supported at first hand.<br />
      As written it accepts an input which will be compressed as is.<br />
      When the input you provide does not conform the needed structure the resulting compressed file will also not conform it.</p>

      <p>When you need this sort of feature, the manual change of archiv files by adding folders into existing archives, or change existing archives by adding files, you should wait until Zend_Compress or similar is available, or you can propose this yourself.</p>

      <p>Btw:<br />
      Why do you think that it's functionallity is limited ?<br />
      Which sort of options will be supported is not described because, as already noted, this differs from adapter to adapter. And for me it's useless to work this all out as long as the whole proposal is not accepted <ac:emoticon ac:name="wink" /></p>

  4. Mar 27, 2009

    <ac:macro ac:name="note"><ac:parameter ac:name="title">Zend Acceptance</ac:parameter><ac:rich-text-body>
    <p>This proposal is accepted for development in the standard incubator. While we would like to see a Zend_Compress/Decompress top-level component, our ideas and goals for such a component are beyond the scope of this particular proposal at this time.</p>

    <p>We do have the following criteria to add to this proposal, however:</p>
    <li>Must allow compression/decompression of <em>strings</em> as well as files. Compression and decompression is not limited to files, and the filter should not impose such a limitation (unless the selected adapter does).</li>
    <li>Must refactor to use Zend_Compress once that component has been developed</li>

  5. Sep 21, 2009

    <p>The Adapters approach is very good. I agree that this feature should be defined within a component rather than a filter.</p>

    <p>Is there good reasons to define the Zend_Filter_Compress_Interface? Maybe the component can live without it...</p>

    <p>Some points I would observe:</p>
    <li>Verify if the PHP contains the properly extension ('zip' for example) on component construction;</li>
    <li>Provide methods to extract a whole compressed file as well as specific files - defining a extract(array $files = null) method;</li>
    <li>Provide methods to add new files to a compressed file - before compress it.</li>


    1. Sep 21, 2009


      <p>This component is already within ZF Core. The points you want to observe are already available.</p>

      <p>Why don't you simply look at the existing component, work with it, read the manual for it, and fill an feature request to Jira when something is missing in your opinion.</p>

      1. Sep 22, 2009

        <p>Sorry, I did not payed attention to the milestone area. I will take a look at component and manual and see if I can contribute if something.</p>

        <p>Thanks for the reply</p>