Is the service trait still needed?

[tailhook]

trafficstars

As FramedIo now Stream + Sink the server Service is also basically Stream + Sink.

Here is how I can make a server example (also note I don't need any boxing to reply with a future):

            let (stream, sink) = socket.framed(Codec).split();
            sink.send_all(
                stream
                .and_then(|original_line| {
                    Timeout::new(Duration::new(5, 0), &handle).unwrap()
                    .map(move |()| format!("after timeout: {}", original_line))
                })
            )

And pipelining with a limit of 5 inflight request is done in one line using buffered combinator:

            let (stream, sink) = socket.framed(Codec).split();
            sink.send_all(
                stream
                .map(|original_line| {
                    Timeout::new(Duration::new(5, 0), &handle).unwrap()
                    .map(move |()| format!("after timeout: {}", original_line))
                })
                .buffered(5)
            )

For client protocols the code might be more complex, but presumably client protocol is a Sink which embeds futures::oneshot::Complete in it, or somesuch, I need more experimentation with that.

And I think this solves 90% of the backpressure story this way.

[alexcrichton]

Yeah I was wondering if service still pulls its weight as well. For pipelining I don't think it may do so, but I could imagine that for multiplexing the story is more complicated that it may not be expressed via combinators. That being said I haven't though too too hard about this yet.

[carllerche]

The Service trait is an abstraction that provides a foundation for a request / response interaction that is symmetric across clients and servers and agnostic to the underlying protocol. It provides the foundation needed to build reusable components that are common across protocols as "middleware". Also, given that the API is symmetric for clients & servers, these middleware components are useable both in the client and the server.

If there is an alternate strategy that satisfies the stated goals, I would be happy to talk about it, but i don't see how using Stream + Sink satisfies this. Especially since protocol agnostic request / responses can't really be supported w/ Sink as it is.

All effort to date has really been around futures & tokio-core. I expect as that side of things stabilizes, effort will be redirected higher up the stack.

[pyrossh]

Well the server doesn't need to respond always in case of websockets. Is the response always required? https://github.com/housleyjk/ws-rs/issues/111

[carllerche]

@pyros2097 The Service trait is for request / response oriented protocols, which is not an all inclusive category