Conversation
|
Nice one, I'm trying out this branch with my project and are getting the following error in a grpc call that uses
Working through the issue to see if I can find where I might have gone wrong |
|
Whoops never mind my bad; I accidentally picked the wrong role (should have been |
|
@tottoto are there any outstanding blockers to this going in? Hoping for it to be in the next release so I can stop depending on a branch |
|
I was thinking again about the API to be made public, and considering that Alternatively, it seems that using EncodeBody for both the client and the server is what is causing the complexity, so one option would be to separate it into one for the client and one for the server, and have each focus on a simpler role. However, this would be a relatively big change, so it does not seem to need to consider it for now. |
|
As someone that use both the original api and this new one, I found no issues with the new one; it made perfect sense to need to pass a single enum variant to indicate what direction the encoding was happening. Worth pointing out too that this api is really only for advanced users writing complicated middleware that need to peek/modify the inbound/outbound message bodies so imo the ergonomics of this one call is far overshadowed by the complexity of having to deal with creating a new tower layer. |
9863fd9 to
e37e1ab
Compare
e37e1ab to
66a2ab1
Compare
| U: Stream<Item = Result<T::Item, Status>>, | ||
| { | ||
| // `source` should be fused stream. | ||
| impl<T: Encoder, U: Stream> EncodedBytes<T, U> { |
There was a problem hiding this comment.
nit: I still prefer the where style when there is 1+ generic, can be done in follow up.
Follow-up to #1884 to simplify the newly public low-level
EncodeBodyAPI.cc @zakhenry