-
Notifications
You must be signed in to change notification settings - Fork 25
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
Implement conversion from VarSeq
and relax equality comparison
#66
base: main
Are you sure you want to change the base?
Conversation
this adds a manual implementation of `PartialEq` to treat different variants with the same key value as equal. Previously `VarSeq::Seq1(1) != VarSeq::Seq2(1)`, with this change they are treated as equal.
This was intentional, my intent is that the server should ALWAYS treat the sequence number as more or less opaque, and that servers should always return the same VarSeq as is provided by the client, as the server can't know if this is "significant" or not.
EDIT: I see this is not the case as you promote both to u32 to compare, which is the correct thing to do: impl PartialEq for VarSeq {
fn eq(&self, other: &Self) -> bool {
Into::<u32>::into(*self) == Into::<u32>::into(*other)
}
} I still worry a bit that it could be "too easy" to accidentally truncate somewhere and cause unexpected behavior. In general, my rules have been:
†: the one exception to this is I would be open to |
One place where this collision could still occur is in the host client matching of incoming endpoint responses. Approximately here. If the host sends two Seq2s of the same Key (in flight at the same time), |
Thanks for your explanations. I also looked a bit more into the flow of the sequence numbers. I totally agree that the server should not do anything to the sequence number and pass it back as is, after a bit of rework this is how the messages are handled in my implementation now as well. With that assumption this change shouldn't create any problems (as it explicitly rules out your last example), however it's probably best done after rigorous testing. A bit of background why I want this in the first place: I am building a framework where an initial call to an endpoint starts a longer running operation. While it is running the server sends data it generates as While looking through the code I wondered whether it would make sense to choose the sequence length on the server automatically. Currently the |
I'm afk for the moment and will add specific links in a bit, but: "endpoint request with topics out as a multipart response" is something I do as well, check out the schema discovery code in the server and client. I'd be open to formalizing the semantics of this a bit, if you want to open an issue so we can hammer out the details. There's two flavors to this I've done:
|
As I am sending sequence numbers around to reference it in other operations I extended
VarSeq
a bit. I implemented conversion intou8
,u16
andu32
.This also adds a manual implementation of
PartialEq
to treat different variants with the same key value as equal. PreviouslyVarSeq::Seq1(1) != VarSeq::Seq2(1)
, with this change they are treated as equal. For me this is the correct way to handle it, as the value is the important part, the variants are only to save bytes where possible. This might however be different to how the library expects it.