Expose codec configuration

[jkushmaul]

Several issues, including my own I was about to create - are asking for exposing some specific configuration option for the implementations -

I was writing a 7z reader, which requires me to decode lzma using properties which are not in the stream - totally possible with lzma - but it just is not exposed to me in async-compression.

I had actually created a new branch that did this for just that codec - and a function to create the implementation with that stream - but then I saw several other issues of a similar nature so I reworked this to just expose codecs and offer the option to do this across the board.

main...jkushmaul:async-compression:expose_codecs

What I don't know, is if there is some reason to not expose the codecs mod. I can start the PR from that branch but I wanted to ask first.

The other issues this may, or may not help are:

• !335 Configurable block size

  I don't exactly understand what they are asking for, I imagine there is some option on bzip2 that allows this, there's no example so we'll never know. But if there were - rather than string that through in some way - just allow constructing the codec with the bzip2 struct...

• !329 `Expose set_pledged_src_size as a public API for zstd compression

  Similarly, If the underlying zstd struct already supports this - rather than string that through, just allow creating the codec right from one of these structs.

• !324 factor out codec into a separate crate

  Not exactly related - other than they are not exposed, so the issue exists.

  ---

Thanks for taking the time

[NobodyXu]

#325 does expose the codec in a separate crate, that would reduce API maintenance burden of async-compression and improve compilation time.

Having ability to build decoder/encoder from codec does make sense, though I personally would want to have codec in a different crate

[jkushmaul]

It looked like that was dead for 5 months now so I wasn't seeing it as being something usable - this doesn't require any api changes at all. you'd just bump your version up to next minor and you get the extra but the api remains the same.

If the original author isn't going to resume it, I supposed I could try to pick it up if that's Ok. I don't need the separate crate, I just need the exposed codecs so it wasn't my first choice but I could do that if you think it's gone stale.

[NobodyXu]

Yeah I think the original author doesn't have time to fix the CI and resolve the merge conflict.

I'd appreciate if you are willing to pick it up and fix the CI

[jkushmaul]

Yeah I can take a look at it - I didn't set out to rewrite the entire thing - I just wanted to change some vis... (And add vis functions to allow using the new vis) - but not change anything. But I can take a look at this -

Do you still want this PR pretty much as is - just the conflicts resolved? (And obviously - the pipeline passing once that's resolved, goes without saying) - but did you have any issues you wanted changed that you would not have otherwise mentioned in the PR - since I'm starting new on it effectively, is a good time.

[NobodyXu]

No I don't have anything else that I'd want to change, just fixing the CI and merge conflict, then I'd willing to merge it

Thank you for picking it up!

[jkushmaul]

Ok, I'm early in - so if original author comes in - I will hold, but otherwise working on it, thanks for bearing with me through this. It's my first public PR not on my own projects...

[jkushmaul]

Ok sorry for one more Q - sub-crates don't inherit the name of the parent it looks on crates.io - they just show up as their name, verbatim - so the compression-codecs crate - will be that on crates.io - do you want to namespace those with the name of the parent crate, async-compression-codecs instead - I think that's my last question and it' not entirely important at this point anyways if you need to think on it. It's an easy rename on a review I think (Or I just don't know about public crates + subcrates etc - and it will already have the namespace in there - no idea)

[NobodyXu]

I think compression-codecs makes sense, given that there is nothing async in it and it's actually a sand-io library.