-
Notifications
You must be signed in to change notification settings - Fork 74
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
Update Expected Method handling #23
Update Expected Method handling #23
Conversation
Codecov Report
@@ Coverage Diff @@
## master #23 +/- ##
==========================================
- Coverage 81.60% 80.89% -0.71%
==========================================
Files 8 8
Lines 2571 2586 +15
==========================================
- Hits 2098 2092 -6
- Misses 473 494 +21
Continue to review full report at Codecov.
|
This way of doing it doesn't fix the issue #21, as it still relies on strings for which there is no compiler checking. |
It still has to use string because we are encoding messages using serde here teleport-transactions/src/messages.rs Lines 102 to 104 in 9ddd6db
Every message has a Which is then converted here Because this string is generated from serde we can expect it will always have string from a specific set (name of enum variants). I am not sure what other assurance we can get unless we change the encoding itself, as discussed here #19. If we are talking about removing string conversion from messages, we basically need to have other encoding methods, which is beyond the scope of this PR. In Issue #21 I thought the intend was to get rid of the control list as a I think this PR can stand on its own, as irrespective of how we encode stuffs its better to have an enum here than a list of strings as allowed methods. The total removal of strings in message method field can happen later depending on what we decide in #19 |
70f8104
to
1790387
Compare
There was a misunderstanding. String comparisons are not bad by themselves, the bad thing is using string comparisions instead of enum comparisons, because enum comparisons are subject to checking by the rust compiler. Removing string entirely as suggested in #19 is missing the point. If you used bytes (e.g. 0x01, 0x02, etc) instead then there still would not be compiler checking, because typos such as 0xe1 would not be detected by the compiler. I imagine the maker main loop to work where it has an enum that defines which messages it will accept. The main loop would be a big Here is some pseudocode for how I imagine the maker main loop to work without string comparisons (or rather, with string comparisons only inside the serde crate)
A few points:
|
Ah ok, thanks for the detailed explanation. I did misunderstood the objective. Have updated the PR to address the same. To reiterate my understanding:
Rewriting the previous commit as it will make the review easier. Rebased on current master. |
Thanks for the update. I've added some comments and style. Your understanding is fine I think. Except for this:
I think the serde crate might require a method variable, because otherwise it doesn't know which struct to deserialize a message into. That's okay from our point of view because we still only deal with enums, as long as the string (or byte) comparison happens inside serde and not in our code. |
Rename "method"s to "message"s as it sounds more intutive. Expected Messages is now an enum structure. `handle_message()` function reads the expected message variannt recorded in connection state and tries to read message from taker according to expectation, and Update the state correspondingly. Upon recieving unexpected message, it throws protocol error.
Thanks for the comments. Updated accordingly. Just to clarify my understanding
If we move out from serde serialization to something else then we won't need this method flags anymore right? |
On further thought it seems because |
Fixes #21 , Tried few options, it seems the simplest thing to do for now is to use an
ExpectedMessage enum
instead of&str
.if let
probably doesn't make much sense here, because some kind of matching has to happen somewhere. And we cant do itoutside
handle_message()
also as it needs wallet and rpc links.Using message mapping
if let
s ends up having same amount of code, and I don't think it improves any performance.Updated the name "method" to "messages" as it makes more intuitive sense to me and they mean the same thing anyway.
If anything more that can be improved, let me know.