-
Notifications
You must be signed in to change notification settings - Fork 132
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
framing-sv2
doc cmts to conform to standard
#1179
base: main
Are you sure you want to change the base?
framing-sv2
doc cmts to conform to standard
#1179
Conversation
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
we should take this opportunity to add a |
e93c055
to
4bdf140
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #1179 +/- ##
=======================================
Coverage 19.36% 19.36%
=======================================
Files 164 164
Lines 10811 10811
=======================================
Hits 2094 2094
Misses 8717 8717
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
28d8ae9
to
222829a
Compare
A couple notes of areas of improvement:
|
e2edf20
to
b2d1e41
Compare
b2d1e41
to
11282cc
Compare
a327909
to
9677dff
Compare
protocols/v2/framing-sv2/README.md
Outdated
Encode and decode standard Sv2 frames, detailing the message serialization and transmission | ||
process for unencrypted communications. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should avoid bringing up "unencrypted" here... sure, the example is unencrypted, but from a conceptual standpoint, a Sv2Frame
can be serialized into bytes just like on this example, and later be transmitted over an encrypted channel
so drawing attention to "unencrypted" here is misleading
9677dff
to
6fdeb5f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think my handshake.rs example does a great job of showcasing the handshake framing logic. Any feedback would be great, and I can always delete it if it is not helpful.
indeed, I don't feel we're really showing anything useful to the reader here
when you really look at it, HandShakeFrame
is nothing but a simple wrapper around payload: Slice
, and its methods don't really do anything fancy:
get_payload_when_handshaking
has a big name, while it's nothing but a getter for the innerpayload
encoded_length
which just returnslen()
for the innerpayload
from_bytes
andfrom_bytes_unchecked
are a simple constructor (and both methods are actually redundant)
so I guess there's nothing that really justifies a dedicated example around HandShakeFrame
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I remember we used to have a Frame
trait on this crate, which has already been removed via #976 because while it aimed to unify Sv2Frame
and HandShakeFrame
under the same interface, the trait was never really used as a trait bound anywhere
By trying to unify Sv2Frame
and HandShakeFrame
under the same interface, we ended up with the worst of both worlds, with a rather wonky and unintuitive API for both
Sv2Frame
is on its way to be improved via #1033
I wonder if we even need HandShakeFrame
, but getting rid of it would have implications on enum Frame
and StandardEitherFrame
(from codec_sv2
), so unfortunately it's non trivial.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for that context, very helpful. Let me think on it a bit more.
we should bump see #1221 for more details edit: it was pointed out on #1222 that we should probably start bumping PATCH instead I started a new Discussion on Standardization of Docs #970 (comment) |
6fdeb5f
to
b01167b
Compare
Addresses #1178.