-
Notifications
You must be signed in to change notification settings - Fork 134
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
refactor: framing.rs
api
#1033
base: main
Are you sure you want to change the base?
Framing
refactor: framing.rs
api
#1033
Conversation
e87cba7
to
9474b3b
Compare
#[derive(Debug)] | ||
pub enum Frame<T, B> | ||
where | ||
T: Serialize + GetSize, |
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.
Best practice is to constrain generics only where you need it.
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.
In the impl block where you have function that need the generics to be constrained
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.
Having naked generics makes it really hard to read the enum
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 get it. Why is harder?
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.
Maybe you want to use InnerType and Buffer instead of T and B ?
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.
previously it was only Frame<T,B>{ HandShake(HandShakeFrame), Sv2(Sv2Frame<T,B>)
without any info about T and B
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 dont feel very strongly about it, but I would appreciate reviewing the full PR (:
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 went trough the code everything look very good to me.
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.
what is the outcome here?
@Fi3 do you still feel need we shouldn't be constraining generics here? or looking at the rest of the PR change your mind?
should we drop this commit from the PR?
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.
constrain generics where not needed is bad, so my opinion is the same. If you are concerned about readability you can use Frame<InnerType,Buffer> instead of Frame<T,B>
f30003a
to
d185f35
Compare
Framing
refactor: fix functions signature in framing.rs
Framing
refactor: framing.rs
api
// Gets the message payload | ||
let payload = incoming.payload(); | ||
let payload = match incoming.payload() { |
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.
This seems like a place where clippy would complain to use if let Some . But if clippy is happy I'm as well. Maybe since you are at it you could just remove the above comment.
d185f35
to
aaa542b
Compare
@jbesraa it seems we're breaking https://github.com/stratum-mining/stratum/actions/runs/9889295180/job/27315027024?pr=1033#step:8:437 |
aaa542b
to
3c322e4
Compare
oops missed this, it should be fixed now @plebhash |
`Frame` is defined with `T` and `B` generics but the constraints are only introduced in the impl level which makes it harder to read the enum and understand whats those generics are about. As those generics are a key part of the `Frame` enum, it makes more sense to introduce the constraints in the enum level.
..instead of panicking
Remove `Option` from its return type.
`Sv2Frame` can handle serialized and non-serliazed data, both scenarios were previously in the same struct wrapped by Option, where if one is Some, the other is None but never both None or Some.
3c322e4
to
d1d9247
Compare
@jbesraa FYI I solved some conflicts here, which is why I'm co-authoring the commits |
@@ -44,11 +44,9 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> From<Sv2Frame<T, B>> | |||
|
|||
/// Abstraction for a SV2 Frame. |
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 expand this comment to make it clear what each enum
variant is
maybe something like:
/// Both `Payload` and `Raw` variants carry the `Header` as metadata
/// `Payload` means the `Sv2Frame` carries a payload, but it has not yet been serialized
/// `Raw` means the `Sv2Frame` has been fully serialized, where the `serialized` field contains both `header` + `payload`
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
@@ -57,23 +55,23 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
/// When called on a non serialized frame, it is not so cheap (because it serializes it). |
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 update these comments so that they are coherent with the new behavior of this function
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
@@ -83,16 +81,18 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
/// already serialized payload. If the frame has not yet been |
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 update these comments so that they are coherent with the new behavior of this function
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
@@ -91,8 +91,8 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
} | |||
|
|||
/// `Sv2Frame` always returns `Some(self.header)`. |
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 update these comments so that they are coherent with the new behavior of this function
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
@@ -113,10 +113,9 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
pub fn from_bytes_unchecked(mut bytes: B) -> Self { |
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.
Github doesn't allow me to add this comment on the lines above. Ideally this comment should be placed on line 98, but placing it here should be sufficient
the comments on from_bytes
are outdated with regards to the new enum
-based Sv2Frame
we should update these comments so that they are coherent with the new behavior of this function
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
@@ -150,13 +149,9 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
/// otherwise, returns the length of `self.payload`. |
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 update these comments so that they are coherent with the new behavior of this function
updating the comments is especially important given that these are used on the Rust Docs, so they need to follow these changes accordingly
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.
strong ACK on converting Sv2Frame
from a struct
into an enum
the previous APIs around the struct
were very confusing for the user, and also had some panics on edge cases, which IMHO is not the best way to design an API
so this is making things much better!
however, we need to also update all comments accordingly, otherwise we will be generating outdated Rust Docs
I'm also seeing some CI things blowing up after I solved a conflict
@@ -83,16 +81,18 @@ impl<T: Serialize + GetSize, B: AsMut<[u8]> + AsRef<[u8]>> Sv2Frame<T, B> { | |||
/// already serialized payload. If the frame has not yet been | |||
/// serialized, this function should never be used (it will panic). | |||
pub fn payload(&mut self) -> Option<&mut [u8]> { |
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.
shouldn't we rename this method?
with the new enum
we are sort of establishing a convention where the Payload
variant signals that Sv2Frame
has not yet been serialized
so calling a method that is named payload
for a Sv2Frame::Payload
and getting a None
is extremely counter intuitive!
I feel we would create a more sane user experience if this method was called raw
or serialized
Thanks for doing that. Please next time just write a comment and I'll rebase. It's gonna be tricky for me now to understand what you did or what were the changes in dev that caused conflicts. |
it was some small conflicts on basically I just had to adjust some calls to but I understand how that was potentially counter-productive on your side, and I will avoid doing this again in the future. apologies again! |
let's revert this to draft for now, we should aim to finish docs and have a refined and wide collective understanding of |
Converted to draft until all documentation issues in #845 are addressed, all refactor issues are complete, and we have team discussions/consensus on path forwards to |
framing-sv2
Crate refactor p3, previous prs #982 #976Partially resolves #903
In this pr I started working on the exposed API from
framing.rs
by handling the errors in a nicer way and also be more consistent with the naming