Determine the future of tokio-proto

[carllerche]

The tokio-proto crate was part of the initial release of Tokio. At that point, Tokio was focused on providing a higher level request / response based API and the I/O reactor was an implementation detail.

Today, focus has shifted and Tokio is now primarily a non-blocking I/O library and the request / response aspect is being shifted to Tower (which has not yet been released).

One problem that tokio-proto faces was that it was trying to be a one size fits all solution to binding Service to a socket. It tries to provide many capabilities at the cost of significant complexity. Even with all these features, libraries like h2 have opted to not use it.

That said, the idea of tokio-proto still has value in providing an easy way to bind a socket to a service. Ideally, the next iteration of tokio-proto would be significantly simplified to assist with getting something working fast with the assumption that, if advanced features are required, one would not use the library.

Now, resources to maintain development of tokio-proto are currently limited. So, I would ask the community there is any interest in a simplified tokio-proto and if there are any volunteers willing to take on some of the burden in developing & maintaining the crate.

[flosse]

So, I would ask the community there is any interest in a simplified tokio-proto

yes :) I already asked for some clarification: tokio-rs/tokio-proto#202

and if there are any volunteers willing to take on some of the burden in developing & maintaining the crate.

I won't be able to spend much time but I could give some feedback as a library developer.

[djc]

Although I tried very hard to use tokio-proto for tokio-imap, it didn't work out. I now believe tokio-proto's main value is probably in optimizing simple request/response flows, but I feel that it probably makes more sense focusing on tokio, tokio-io and other parts of the futures stack for now.

[flosse]

@djc Thanks for the insights. This leads to my thoughts to totally deprecate tokio-proto. It might be better to avoid it completely than to use a non-maintained unfinished crate.

[inejge]

[It's been suggested on Gitter that I open an issue similar to this one; I saw the one mentioned by @flosse and intended to respond there, but this is an even better place.]

I concur with @flosse that an heir to tokio-proto should exist. I've used tokio-proto pretty extensively, choosing to work around its limitations instead of replacing it with custom code, and IME it worked rather well. The chief pain points I've noted were, in no particular order:

• It's a maze of twisty little traits, all similar (but with some baffling differences, e.g., error types in simple vs streaming variants). Small wonder, since it aims to support three independent axes: client/server, each pipelined or multiplexed, with simple and streaming flavors on top of that. That's eight scenarios, and it can be very difficult to map your problem to this space.

• Some types of errors would be swallowed by the exchange machinery, leaving the user with a generic "Broken pipe", necessitating the use of tracing to find out what really happened.

• Trying to accomplish things not directly provided by the trait facades, like explicitly closing the underlying I/O source, would lead to loss of genericity and, effectively, manual monomorphization, with an explosion of types, impls and boilerplate.

That may sound quite critical, but I'll reiterate that my overall experience with the crate was quite good. I especially liked the ease of slotting in a completely separate type of transport (Unix domain sockets) in a client when the need arose, as well as the fairly modest set of changes required for implementing things like StartTLS, after some type wrestling.

I think that the division of protocols into pipelined and multiplexed is sound and essential, but that streaming variants are adding more complexity than necessary, and that the crate would be majorly simplified by ditching them. Furthermore, client and server roles could be separated into their own crates, leaving the users a much clearer choice and a lower cognitive burden.

I intend to analyze tokio-proto's reverse dependencies too see how disruptive the jettisoning of streaming would prove, fork the codebase to implement the simplifications outlined above, and try to provide some enhancements, like accomodating almost-request/response protocols, where some messages are unidirectional while the majority are not. The pace of activity is not something I can make promises about, but I hope that my work during the year can lead to simplified and revamped tokio-proto which will be useful to existing and new Tokio users.

[carllerche]

@inejge Great to hear.

I do think that a simplified tokio-proto has value. The primary issue is that this is pretty close to a rewrite and my time is currently pretty limited.

If you have availability to take on the work, I can provide guidance.

[flosse]

It's interesting: there are 46 crates that depend on tokio-proto but there are only 4 developers who are concerned about the future of this crate. I wonder if it makes sense to invite the other authors to this discussion? What do you think?

[tikue]

I've used tokio-proto because it's the fastest way to get off the ground, and I trusted @carllerche to write a better and more performant server implementation than I would with the time I have. If it didn't exist, I'd probably just settle for a simpler, less performant server implementation.

[RadicalZephyr]

I'm in the process of starting a project that is using tokio to implement a simple line based protocol over serial lines, and using tokio-proto has really saved me a lot of time in structuring the code in a request/response model. So I'm very interested to see it continue in some form, and a simplified verion as described by @inejge sounds pretty ideal to me.

I would be happy to help with that effort, though I can't commit a ton of time to it.

[carllerche]

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

[rustonaut]

TL;DR: take tokio-proto split it into a non-tokio specific service crate and a crate for impl protocols and focus this on tools helping you implement on aspects each instead of providing a frameworkish interface like tokio-proto currently does.

My experience with tokio-proto was:

• I love the idea behind it
• it can be quite a maze of traits associated types etc.
  making it more confusing than it should be if you start
  using it (or haven't used it for some time)
• it expects to much that the protocols are "well designed"
  being annoying to use if they aren't
• thinks like protocol upgrades and similar can be annoying to
  implement (e.g. STARTTLS in SMTP)
• it turned out that "just" using tokio/tokio-io/bytes etc.
  might require more code but can be easier to implement, read
  and maintain for some protocolls*
  Through you might do some thinks in a less good way but
  then tokio also might not do them well and finding out if it
  does can be quite annoying.
• The service trait implements an interface which looks nice but
  drops any aspects of back pressure also even when wanting to
  drop back pressure I had the experience that when I moved away
  from it thinks got simpler... Through I cant quite put the hand on
  what exactly the problem is with this trait.

*this is my subjective experience when playing around with tokio and e.g. implementing smtp

I cam to the believe that instead of having tokio-proto it might be better to have
two independent thinks:

1. a library focusing on making it easier to wite your own service instead
   of trying to have a "fit all" abstraction of services. (Through then having
   some form of interface for middle ware is nice to). This should not be
   bound to tokio at all but a library for users of futures, which might happen
   to be for tokio.
2. a library providing tools for making it easier to implement protocols for
   tokio, no framework or abstract protocols just tools. This can e.g. include
   some tool for reading from a socket into a buffer until a full input part was
   read (e.g. an line) handling thinks like growing the buffer but also e.g.
   maximal input buffer size.