Skip to content
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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from

Conversation

jbesraa
Copy link
Contributor

@jbesraa jbesraa commented Jul 4, 2024

framing-sv2 Crate refactor p3, previous prs #982 #976
Partially 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

@jbesraa jbesraa force-pushed the 2024-07-02-framing-refactor-p3 branch 2 times, most recently from e87cba7 to 9474b3b Compare July 4, 2024 12:09
#[derive(Debug)]
pub enum Frame<T, B>
where
T: Serialize + GetSize,
Copy link
Collaborator

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.

Copy link
Collaborator

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

Copy link
Contributor Author

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

Copy link
Collaborator

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?

Copy link
Collaborator

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 ?

Copy link
Contributor Author

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

Copy link
Contributor Author

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

Copy link
Collaborator

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.

Copy link
Collaborator

@plebhash plebhash Aug 20, 2024

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?

Copy link
Collaborator

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>

@jbesraa jbesraa force-pushed the 2024-07-02-framing-refactor-p3 branch 6 times, most recently from f30003a to d185f35 Compare July 8, 2024 11:44
@jbesraa jbesraa marked this pull request as ready for review July 8, 2024 11:45
@jbesraa jbesraa changed the title Framing refactor: fix functions signature in framing.rs Framing refactor: framing.rs api Jul 8, 2024
// Gets the message payload
let payload = incoming.payload();
let payload = match incoming.payload() {
Copy link
Collaborator

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.

@plebhash
Copy link
Collaborator

plebhash commented Jul 15, 2024

@jbesraa jbesraa force-pushed the 2024-07-02-framing-refactor-p3 branch from aaa542b to 3c322e4 Compare July 16, 2024 13:54
@jbesraa
Copy link
Contributor Author

jbesraa commented Jul 16, 2024

oops missed this, it should be fixed now @plebhash

@plebhash plebhash self-assigned this Jul 16, 2024
@rrybarczyk rrybarczyk requested a review from plebhash July 17, 2024 13:58
@plebhash plebhash linked an issue Aug 20, 2024 that may be closed by this pull request
`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.
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.
@plebhash plebhash force-pushed the 2024-07-02-framing-refactor-p3 branch from 3c322e4 to d1d9247 Compare August 20, 2024 22:46
@plebhash
Copy link
Collaborator

@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.
Copy link
Collaborator

@plebhash plebhash Aug 20, 2024

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).
Copy link
Collaborator

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
Copy link
Collaborator

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)`.
Copy link
Collaborator

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 {
Copy link
Collaborator

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`.
Copy link
Collaborator

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

Copy link
Collaborator

@plebhash plebhash left a 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]> {
Copy link
Collaborator

@plebhash plebhash Aug 20, 2024

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

@jbesraa
Copy link
Contributor Author

jbesraa commented Aug 21, 2024

@jbesraa FYI I solved some conflicts here, which is why I'm co-authoring the commits

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.

@rrybarczyk rrybarczyk self-requested a review August 21, 2024 18:09
@rrybarczyk rrybarczyk added protocols Lowest level protocol logic refactor Implies refactoring code labels Aug 21, 2024
@plebhash
Copy link
Collaborator

@jbesraa FYI I solved some conflicts here, which is why I'm co-authoring the commits

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 roles/mining-proxy/src/lib/downstream_mining.rs, which came from merging #1021

basically I just had to adjust some calls to payload and header so they followed the changes introduced on this PR

but I understand how that was potentially counter-productive on your side, and I will avoid doing this again in the future. apologies again!

@plebhash plebhash changed the base branch from dev to main August 28, 2024 19:20
@plebhash
Copy link
Collaborator

plebhash commented Sep 3, 2024

let's revert this to draft for now, we should aim to finish docs and have a refined and wide collective understanding of protocols crates, which will be addressed by the documentation issues listed on #845

@rrybarczyk rrybarczyk marked this pull request as draft September 4, 2024 13:55
@rrybarczyk
Copy link
Collaborator

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 protocols refactoring.

@stratum-mining stratum-mining deleted a comment from github-actions bot Sep 5, 2024
@stratum-mining stratum-mining deleted a comment from github-actions bot Sep 5, 2024
@stratum-mining stratum-mining deleted a comment from github-actions bot Sep 5, 2024
@stratum-mining stratum-mining deleted a comment from github-actions bot Sep 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
protocols Lowest level protocol logic refactor Implies refactoring code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

refactor: framing_sv2 crate
4 participants