Emīls Piņķis

I'd be up for simplifying the `Runtime` trait, but just to make it clear, you're suggesting adding instance methods to the runtime itself, right? I'd be up for making those...

>I'm not sure if they need to be instance methods exactly The impetus for all of these changes is to allow for the methods that are used to create sockets...

Having slept a bit on this, consolidating the transport and spawning traits into the runtime trait necessitates moving the runtime trait to the `proto` crate. Or the `Runtime` trait has...

Yep, the recently changed integration test needed to be changed. As for simplifying the `RuntimeProvider` trait, I've gone and changed it without removing the `UdpSocketBinder` and `TcpConenctor` traits. If these...

I've pushed one more update, eliminating the associated types from `RuntimeProvider`. This does increase complexity wherever the type of the socket needs to be typed out, going from an `R::Tcp`...

Coming from the depths of the TCP and UDP code, it doesn't sit quite right with me that `UdpStream` and others would rely on a trait that spawns futures, creates...

Well, I can push a commit that would move the runtime trait to the proto crate and then we can see how that looks. Once I get around to writing...

Fair, I'll push another commit to move the `RuntimeProvider` trait into the protocol trait. Once the commit is written, of course.

I think I've pushed what might look like the final version of changes to move the `RuntimeProvider` crate into the `proto` crate. As always, looking forward to your feedback :slightly_smiling_face:....

Hiya, it seems that these changes are due for a rebase and some of the As for the issue with static versus instance methods, I personally feel like the `Runtime`...