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
-
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