Replies: 1 comment 1 reply
-
Thanks for the writeup, you tackled both side well! As you noticed, the frame design was made for forwards-compatibility in mind. Not with a specific immediate need, but to allow for new frames from h2 or h3. Because that was its entire purpose, I lean most towards keeping it maximally flexible. I do appreciate that makes it harder to tee the stream... |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
Hi!
I am aware that the change to a
Frame
enum was made to allow users to give their ownFrameish
implementation.Though this has not been done yet, I assume it is still relevant and will be done eventually.
I would like to propose that
Frame
should implementClone
and thus that the futureFrameish
trait also be bounded byClone
. This allows the consumer of a body to broadcast those frames to multiple consumers without having to aggregate all the body first. This would not be a breaking change right now, that is why I am proposing it before the trait is implemented.I do get that it is always better to not introduce this restriction since we don't really know what use-cases might be for
Frameish
, but at the same time I don't think it is that much of a bar since worst case the users can wrap their frame decoder inBytes
to make them clonable.Beta Was this translation helpful? Give feedback.
All reactions