Consider Approaches to Borrowed Data in `Service`

[tower-rs]

Consider Approaches to Borrowed Data in `Service`

[aturon]

There's a lot to think about here, but one thing that strikes me is: if we do find a good solution to this problem, it should be possible to introduce it without too much disruption, because existing Service implementations should be trivially transformable to the CPS'ed version. (Could do this via a blanket impl etc). Does that seem right? If so, I think it eliminates any urgency here.

[cramertj]

@aturon Yep, it'd be easy to wrap the current Service::call in a res.send(Service::call(req)). The blanket impl only makes sense in that direction, though, so middleware based around Service wouldn't be trivially compatible with NewService.

[seanmonstar]

Passing a Sink to as responder may be a separate topic from borrowing (or maybe its the only kind of borrowing you'd want?), but I'll comment about it specifically: the idea of Service is to serve RPC, where you have a single response for a request. A Sink implies being able to to send multiple items back. I suppose an item could implement Sink and only be allowed to send a single item, but then we've moved that constraint from compile-time to run-time.

[aturon]

@seanmonstar For HTTP, think about response bodies, where you might produce the body in a series of chunks -- much like the BufStream trait in tower-web.

[seanmonstar]

@aturon I don't quite see the connection there. Do you mean if it were Sink<ResOrBuf<B>> with enum ResOrBuf<B> { Res(Response<()>), Buf(B), }?

[cramertj]

@seanmonstar Good call-- Sink isn't exactly what you want-- it's really trait Send<T, E> { async fn send(self, T) -> Result<T, E>; } or something.

[carllerche]

I don't believe there currently are any actions to take from this issue, so I'm going to close it. Please let me know if this is an incorrect conclusion.