Reverse dependencies with asynchronous-codec

[thomaseizinger]

The asynchronous-codec crate defines the Encoder and Decoder traits, some utility codecs AND several that are feature-flagged: https://github.com/mxinden/asynchronous-codec

I think it would be cleaner if unsigned-varint would not depend on asynchronous-codec and we instead add a feature-gated codec to asynchronous-codec.

Thoughts?

[mxinden]

No opinion. Off the top of my head, cleaner but not a high impact.

[thomaseizinger]

I thought some more about this and came to the conclusion that whilst asynchronous-codec is < 1.0, it is much easier to have the codec within that crate as they can be all upgraded in one version. Once the interface is mature and 1.0 is being released, it actually makes more sense to have the codecs in external crates.

For example, serde also only provides the interface and the actual formats are implemented externally, in e.g. serde_json etc.

I don't know how far we are from 1.0 in asynchronous-codec but instead of moving the codecs now, it might be worth maturing that crate.

All of this obviously only applies if 1.0 comes with a certain stability guarantee, i.e. no major version bump in the foreseeable future.

[thomaseizinger]

After working on libp2p/rust-libp2p#4782, I came to the conclusion that likely, there shouldn't even be a codec for length-prefixing with unsigned-varint because it can easily lead to lots of temporary allocations.

Thus, I am going to close this issue as a "won't fix". I think it is worth considering removing the impl from this repo to avoid similar inefficiencies on other usage sites.