Tokio support

[vorner]

Hello

As mentioned in #4, I just created a „competing“ crate, whithout the intention to compete with anyone. I have a minimal implementation for async with tokio, which I wanted to extend in the future. It works by turning the interface object into an async object (which no longer supports all the fancy things like getting the name) that implements Sink and Stream.

So, I was thinking, instead of trying to compete, would it make sense if I ported that async wrapper to this crate?

[meh]

That's currently provided through mio, each Device implements mio::Evented which allows it to be used from tokio without doing anything tokio only.

What would be the difference with implementing tokio::Sink and tokio::Stream directly?

[vorner]

I might be missing something, but last time I looked at how Evented is used in tokio with PollEvented, it required quite a large amount of boilerplate code. So, the difference would be putting this boilerplate code into the crate itself so it can be reused, possibly behind a feature gate.

As a slightly related side note, when I discussed my code on the tokio gitter, I was told the Read and Write (and, in context of tokio, AsyncRead and AsyncWrite) traits aren't the best ones, because they assume the underlying object is stream of bytes, not bunch of discrete messages ‒ things like Write::write_all or Read::bytes make no sense in context of a TUN device that returns packets.

In that sense, having a Stream of packets seems like more natural API for that than AsyncRead provided by PollEvented. But having a recv method which returns a future, or a framed method, that takes a Codec and produces a stream of some messages, would make sense too.

[meh]

That's a good point, I'd be fine with a feature-gated tokio implementation alongside the mio one.