Consider moving `mio::timer` and `mio::channel` to a separate crate

[carllerche]

As of now, the channel & timer implementation included in Mio is fully decoupled from the core Poll API.

Given that:

a) There is an effort to build a higher level "batteries included" async IO lib w/ tokio-core.
b) There is no "one size fits all" implementation of timer or channel.

I think that it would be worth to move that code to a separate crate, further reducing the Mio API surface. The Mio readme can link to these crates.

[alexcrichton]

Sounds good to me!

[jwilm]

This sounds like the right thing to do. Just to clarify, are you suggesting two additional crates? I'm imagining something like mio-channel and mio-timer versus mio-extras. Crate per component would be nice to opt-in to only what is needed.

[carllerche]

Well... does it hurt to have one crate if there are no deps?

[jwilm]

Doesn't hurt. I think when we talked at the tokio hack night, you mentioned one of the reasons to pull this stuff out is to make mio itself minimal and could maybe call it "done". I feel like the same reasoning could be applied to the additional Evented impls like timers and channels.

[WiSaGaN]

Would it make sense to have a trait in std that serves as a common interface for different implementations that share the same guarantee such as whether it's blocking, whether it's multiple/single producer/consumer?

[carllerche]

@WiSaGaN Adding a trait in std would require going through the RFC process.

This is going to happen, channel and timer have been flagged as deprecated on master.