Tim

It could be reflected in the type signature like this: ```rust // Given this service: service! { rpc foo() -> Foo | Bar; rpc baz() -> Baz | Error; }...

That's a neat pattern! I've got a branch on my personal repo that has experimental support for task-local contexts. It seems pretty cool, but requiring being on-task is kind of...

I'm pretty sure this will be a lot easier to accomplish now that services are essentially just `FnOnce(Request) -> Response + Clone`. I'm imagining something like...(this is a strawman example,...

Another option (for auth, specifically) is to plug it in at the transport layer, so that it's completely transparent to the user. Effectively, it'd transform a `Transport` to a `Transport`...

The best approach I know of is to use tokio's [`blocking` fn](https://tokio.rs/blog/2018-05-tokio-fs/).

You just wrap a blocking call and it returns a future. So, you'd plug it into a FutureService method.

I think right now the easiest way to achieve parallelism is to run multiple cores, each with an instance of FutureService. That's pretty coarse-grained parallelism -- each client will be...

I'm pretty sure you can simply specify the same port. Did you run into a problem with that? Yeah I think you probably have to create the thread pool first.

Are you using the futures API or the blocking API? With the blocking API, it uses a thread pool. With the futures API, it's just one thread, and you're expected...

I'm sorry if this is all a bit unclear! The futures ecosystem is still in quite a bit of turmoil, which has made it difficult for me to chart out...