Question: What's the future of tokio-proto and should new libraries depend on it?

[flosse]

As a library author I'd love to get some more clarity about the future of tokio-proto.
Within the tokio-reform I can read the following:

So, in general: the future direction for tokio-proto is unclear.

This is not a good foundation for tokio-library developers, is it?

We need to be driven by strong, concrete use-cases.

What exactly do you mean by "strong"?

If you have one of these, we'd love to hear about it!

It might not the most popular use case but nevertheless it is one of many: tokio-modbus.
I recently added a server implementation based on tokio_proto::TcpServer. It kind of works but I don't see that this is the best solution. E.g. there is no way to configure the TcpStream (timeouts etc.).

I love to spend a lot of time to improve the tokio project and the rust ecosystem in general. And to do so clarity would help a lot :)
I really would like to get some feedback on how I should behave.

[nielsle]

I am not a tokio developer, but tower-rs looks like a replacement for tokio-proto
https://github.com/tower-rs/tower

[flosse]

tower-rs looks like a replacement for tokio-proto

I disagree. Looking at the docs it looks like tokio-service. But also they warn us:

This is not ready for usage yet (unless you are brave).

[carllerche]

I created an issue here: tokio-rs/tokio#118

Tower is going to be the replacement for tokio-service. There currently is no planned replacement for tokio-proto due to lack of resources.

The disclaimer re: "not ready for usage" is mostly in regards to everything in that repo that is not the service trait.

[tjkirch]

What's the recommendation for the basic use case of tokio-proto now that tokio 0.2 is out? If you have a pretty clear codec (encoder/decoder) and want to use that from a client, then before, you'd use Client->Proto->Codec and it was fairly obvious. The server end could build a TcpServer using the same protocol definition. Customizing that was hard for me to understand, so I'll be glad if the new direction is clearer, but I'm just confused about how to approach protocol development at the moment.

[flosse]

but I'm just confused about how to approach protocol development at the moment.

@tjkirch you are not the only one ;-)
@carllerche recently created some hope:

Ok, I will try to put together a more organized group to attempt to take over -proto.

But there still seems to be a lack of time :(