First: Configurability / Usability / Simplicity

is better than

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".

Second: Code reduction
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.
Useless in my eyes.

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

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.

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.

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

Third: Automatism
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.

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.

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

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.

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

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.

Btw:
Why do you think that it's functionallity is limited ?
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

@Bruno:

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

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.