-
Notifications
You must be signed in to change notification settings - Fork 141
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
Add sv2-serde-json #1323
Add sv2-serde-json #1323
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #1323 +/- ##
==========================================
+ Coverage 16.90% 18.84% +1.94%
==========================================
Files 164 169 +5
Lines 10956 11207 +251
==========================================
+ Hits 1852 2112 +260
+ Misses 9104 9095 -9
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
Bencher Report
🚨 1 Alert
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
Bencher Report
Click to view all benchmark results
|
What crates will depend on this new |
This change would only impact |
For reference only, I did a Stratum v1 no_std client implementation (https://github.com/Foundation-Devices/foundation-rs/tree/main/stratum-v1) and the json parsing was a nightmare... |
Also I was confused because this new crate have the "sv2" prefix, if it is sv1 oriented (JSON data) or at least not specific to sv2, maybe we should use this prefix? |
makes sense. Its still in POC phase, but if we end up taking this approach I gonna change this name, |
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 am fairly confused about this PR. Can you elaborate why we need this? and why we need to implement a mini serde as utility instead of using serde(if it is really needed..?)
As you may know, we have two versions of
The coexistence of these two implementations is challenging due to conflicting APIs for byte serialization and deserialization. In one of our previous meeting, we decided to develop our own custom JSON serializer and deserializer to replace |
I am still kinda confused. Why actually the message generator need ser/de if its working with sv2 and we already know how to handle sv2 message? Also, in case MG need to do this ser/de, why not add |
MG need serde cause tests are defined as json so it parse one or more json files and then execute them. In order to parse these files it need to do JSON <-> Sv2. Another example of where having JSON <-> Sv2 is helpful is here: https://github.com/demand-open-source/demand-test-data-collector (is outdated and just a POC that I did in order to try the demand-easy-sv2 library, but I can see it's utility) where all the messages intercepted by a proxy are saved as json. |
I see. Why then not add serde to MG and thats it? Why adding serde to MG trickledown to many different crates in the past? |
I don't get the question. If you are asking why we added serde to the binary-sv2 crates in first place, the reason is that,at the start, I did it with serde, then I have been asked to remove serde from it^1, and in order to do it I wrote a completely different library that do not use serde but that expose the same API of the serde one (that cause it was already used in other places). Next step would have been to completely remove serde and we started it, but then it turned out that the library with serde was very handy for the MG so we decided to keep it. Keep in mind that at the time we had only one big workspace and MG was part of it. ^ 1 this was necessary cause the original plan were to use the SRI libs in bitcoind in order to implement sv2, then we changed our minds. |
@Shourya742 after reading again the discussion here, I think the best approach is the one you started: developing a separate specific crate that can be then imported by the Are you facing some particular issues somewhere? Is there anything else you would like to get feedback about? |
9388cf8
to
ae2807d
Compare
191b21b
to
89e0c58
Compare
e14205f
to
ede3466
Compare
@@ -0,0 +1,7 @@ | |||
[package] | |||
name = "sv2_serde_json" |
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.
should we use a more generic name here? this implies it's sv2 only (not sv1)
@Shourya742 should we close this for now and reopen in MG repo? |
Yes, @plebhash and I discussed this PR. We can close it, but I was waiting for today's dev sync call to finalize the path forward for MG. |
This PR introduces a sv2-serde-json as a utility module. The goal is to eliminate the dependency on
serde
from the message generator, ultimately phasing outbinary_sv2_serde
. Currently,sv2_serde_json
handles serialization and deserialization by converting data into aValue
construct, which must then be mapped onto Rust's structs and enums.By adopting this approach, we aim to remove all dependencies on
serde
, paving the way for the eventual deprecation ofbinary_sv2_serde
entirely. Alternatively, if we decide not to proceed with this new utility, we will extend the existingbinary_sv2
to support JSON serialization and deserialization directly.This PR is marked as a draft while we finalize the chosen approach. In the meantime, this branch will be maintained for developing JSON features using the external utility, rather than extending
binary_sv2
.