Compression support for the high-level API #513
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR adds compression support to the high-level encrypt function. The feature was what I needed today, and I thought others might find it useful because some people had also been requesting compression for outgoing messages as mentioned in pull request #272.
By default, the encrypt function still generates uncompressed messages; so the new API maintains backwards compatibility with this new feature added. However, if it comes better to enable compression with no extra parameters as suggested in issue #87; the compress property of the parameter object can be made optional with a default value set to true. I am still not sure whether it was the right way to go but the algorithm to use is taken from the value of openpgp.config.compression. Do you think this is good or it would make a better way to allow parameter passing to override the configuration value for another compression algorithm?
Note: bzip2 is yet to be implemented by low-level objects. zip and zlib appear to be working as expected with decent performance overhead.