[RFE] Asynchronous IO support

[dralley]

Would you be open to a feature that supported Tokio's AsyncRead trait for the underlying IO?

[BurntSushi]

Could you please explain why it's needed? Why can't you create an async Read impl that wraps what's already in this crate?

[dralley]

Because DecodeReaderBytes performs IO using synchronous APIs and because the orphan trait rule prevents implementing foreign traits on foreign types?

If io::Read is the only interface this crate provides and the implementation does blocking IO, I don't see how just "wrapping" this would accomplish anything unless everything that called Read was wrapped in spawn_blocking() or something, which has limitations.

[BurntSushi]

I personally think the ecosystem needs to figure something out that's better than "every crate that does I/O needs to provide impls of traits for every async runtime."

Taking on a massive dependency like tokio for this tiny little library doesn't seem like a good fit to be honest.

Is this the only viable path forward for you? If so, I would consider a patch if it looks maintainable to me.

[dralley]

I pretty much agree with you personally, but I'm in essentially the same situation. The XML library I'm helping to maintain merged async support because someone needed it for a weird network protocol, so now the decoding feature I'm working on needs to be capable of working with that also.

Modifying a vendored copy is always an option if you're strongly against it. There's a few other tweaks we might need to make such as being able to override the decoder sniffing to respect the XML declaration <?xml version="1.0" encoding="UTF-16"?>

[BurntSushi]

See: https://rust-lang.github.io/wg-async/vision/submitted_stories/status_quo/barbara_writes_a_runtime_agnostic_lib.html

Would it be sufficient to support AsyncRead from the futures crate? I imagine you could then write an adapter to bridge with tokio.