You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 12, 2024. It is now read-only.
Structs like what was added in #37 allow consumers of this SDK to parse any JSON message or resource that's part of tbdex. Some fields in a message are strings that are meant to represent numbers. As stated in #37 (comment) there seems to be a need to validate that the values of certain fields. For example, and "amount" fields should likely only have possible amount values, even thought it's serialized as a string in JSON.
One thing I do want to mention though is that tbDEX messages/resources will need to traverse the language boundary from Rust -> other foreign languages. Strings work really well in this regard, third-party crate types not so much.
It's definitely going to be some tradeoffs, but I think we can find a happy medium here. Looking forward to discussing this more!
@amika-sq , would you be able to elaborate on what the constraints are when passing around structs between language boundaries?
The text was updated successfully, but these errors were encountered:
Structs like what was added in #37 allow consumers of this SDK to parse any JSON message or resource that's part of tbdex. Some fields in a message are strings that are meant to represent numbers. As stated in #37 (comment) there seems to be a need to validate that the values of certain fields. For example, and "amount" fields should likely only have possible amount values, even thought it's serialized as a string in JSON.
Importantly, @amika-sq mentions that
@amika-sq , would you be able to elaborate on what the constraints are when passing around structs between language boundaries?
The text was updated successfully, but these errors were encountered: