Tokio has grown into many crates. Maintaining many separate crates requires overhead. I do not believe, in some cases, the benefits outweigh the overhead.
The primary reason to split functionality into crates is to enable releasing breaking changes at a different pace. Collapsed crates can maintain feature flags to enable / disable the various components to provide.
Some possibility of crates to collapse:
As part of this, I would like to propose moving the I/O helpers back into the tokio-io crate. They would be feature flagged, so you could get tokio-io w/ just the traits. AsyncReadExt and AsyncWriteExt would stay in tokio (so that they can include fns that depend on other crates).
The goal is to be able to use the I/O helpers in other tokio crates (like tokio-fs).
tokio-udp
tokio-uds
These have a similar notion of ancillary data, so if/when I or someone gets around to coming up with a safe zero-cost interface to that, having them in one place where they can share abstractions makes sense.
And how about combining tokio-executor with tokio-threadpool and tokio-current-thread
@leaxoy added it to the list :+1:
i know the decisions here are mostly final/already implemented -- but still: what was the reasoning to put process into the tokio-net crate? could have gone into tokio-util or even tokio-executor (as processes are executed, though i understand tokio's use of the word executor differs here, probably a fair amount of confusion was avoided by not moving process there)
Crates are split up by their dependencies. -process depends on mio and -net is the crate that pulls in -mio.
Most crates are now combined.
Most helpful comment
As part of this, I would like to propose moving the I/O helpers back into the tokio-io crate. They would be feature flagged, so you could get tokio-io w/ just the traits.
AsyncReadExtandAsyncWriteExtwould stay intokio(so that they can include fns that depend on other crates).The goal is to be able to use the I/O helpers in other tokio crates (like tokio-fs).