Anthony Dodd

Yea, https://docs.rs/grpc/0.2.1/grpc/struct.SingleResponse.html looks like they are thin wrappers around `GrpcFuture`. Could be problematic.

So, it has been quite some time since this discussion was started. Per the discussion we had going above, the return type of the services (E.G., those which return a...

@autrilla I’ve been using a workaround. Basically I’ve been having the service impl methods call private methods which are async, and then wrap the future in the `SingleResponse` type or...

@autrilla yea, there are a few options you have there, but that is the idea. Manually construct the needed response object. Add the future and any metadata that you need....

Given where async/await is at, and futures 0.3 (plus the [core::future](https://doc.rust-lang.org/core/future/index.html) trait), might be a good time to put together a nightly branch which uses tokio (as opposed to tokio-core...

@stepancheg nice. Glad to hear it. So, it may actually be best to cut over to `tokio` (away from `tokio-core`) first before making the change to Futures03, as `tokio-core` is...

@stepancheg what are your thoughts on https://github.com/carllerche/h2??? The tower-grpc folks are also using it for their up-and-coming gRPC framework via the https://github.com/tower-rs/tower-h2 crate. We might be able to leverage it...

> what are the reasons to move to newer tokio and futures 0.3? A few reasons: - old `tokio-core` crate is deprecated and archived (nothing new happening there). - futures03...

Not yet. It is currently held behind the [`#![feature(futures_api)]`](https://doc.rust-lang.org/unstable-book/library-features/futures-api.html) feature. IMHO, cutting over to `tokio` as the first order of business would probably be a wise move. It runs on...

Well, I will do a code deep-dive tomorrow and see if I can put together a high-level analysis and plan of attack so that we can all coordinate and such....