meta: consider combining crates

[carllerche]

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:

• tokio-executor
  • tokio-current-thread
  • tokio-threadpool
• tokio-net
  • tokio-process
  • tokio-reactor
  • tokio-signal
  • tokio-tcp
  • tokio-udp
  • tokio-uds
• tokio-util
  • tokio-sync
  • tokio-timer

[carllerche]

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).

[Ralith]

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.

[leaxoy]

And how about combining tokio-executor with tokio-threadpool and tokio-current-thread

[carllerche]

@leaxoy added it to the list 👍

[dario23]

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)

[carllerche]

Crates are split up by their dependencies. -process depends on mio and -net is the crate that pulls in -mio.

[carllerche]

Most crates are now combined.