Expose zlib options on cloudflare-zlib

[RReverser]

See #228 (comment).

[alexcrichton]

Thanks! On second thought, though, could the cloudflare_zlib implicitly enable the zlib feature? That should avoid any sort of duplication here in theory.

[RReverser]

On second thought, though, could the cloudflare_zlib implicitly enable the zlib feature? That should avoid any sort of duplication here in theory.

Hmm, maybe. Then you'll need something like cfg(feature = "zlib", not(feature = "cloudflare_zlib")) and such on actual imports, right?

[RReverser]

No, wait, then it will still include libz-sys by accident... Unless there is some elegant approach that I'm missing.

[RReverser]

The only wait to avoid that seems to be something like:

any_zlib = []
zlib = ["any_zlib", "libz-sys"]
cloudflare_zlib = ["any_zlib", "cloudflare-zlib-sys"]

And then making conditions based on any_zlib instead. Wdyt?

[RReverser]

@alexcrichton Somewhat related. I've noticed that higher-level APIs currently don't expose these advanced zlib configurations, which seems a shame because they're much easier to use than Compress / Decompress directly, and sometimes you really need that fine-tuning.

Would you be open to adding either new methods to ZlibEncoder / ZlibDecoder to propagate corresponding params, or adding implementations of From<Compress> / From<Decompress> so that one could create a high-level wrapper for a preconfigured instance?

[alexcrichton]

Well however it may be done I would prefer to avoid having to write any(...) everywhere. Whether that's done by activating the zlib feature or having something like any_zlib I don't particularly mind.

In terms of adding higher-level APIs, yes, that seems fine to me too. I would prefer it if were a separate PR though and for this to not balloon too much.

[RReverser]

I would prefer it if were a separate PR though and for this to not balloon too much.

Oh sure, absolutely.

[RReverser]

Added an any_zlib feature group as described above.

[alexcrichton]

👍