-
Notifications
You must be signed in to change notification settings - Fork 59
pex: update pex messages #352
Changes from 2 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
@@ -6,9 +6,7 @@ option go_package = "github.com/tendermint/tendermint/proto/tendermint/p2p"; | |||||||||
import "gogoproto/gogo.proto"; | ||||||||||
|
||||||||||
message PexAddress { | ||||||||||
string id = 1 [(gogoproto.customname) = "ID"]; | ||||||||||
string ip = 2 [(gogoproto.customname) = "IP"]; | ||||||||||
uint32 port = 3; | ||||||||||
string url = 1 [(gogoproto.customname) = "URL"]; | ||||||||||
} | ||||||||||
|
||||||||||
message PexRequest {} | ||||||||||
|
@@ -17,21 +15,9 @@ message PexResponse { | |||||||||
repeated PexAddress addresses = 1 [(gogoproto.nullable) = false]; | ||||||||||
} | ||||||||||
|
||||||||||
message PexAddressV2 { | ||||||||||
string url = 1 [(gogoproto.customname) = "URL"]; | ||||||||||
} | ||||||||||
|
||||||||||
message PexRequestV2 {} | ||||||||||
|
||||||||||
message PexResponseV2 { | ||||||||||
repeated PexAddressV2 addresses = 1 [(gogoproto.nullable) = false]; | ||||||||||
} | ||||||||||
|
||||||||||
message PexMessage { | ||||||||||
oneof sum { | ||||||||||
PexRequest pex_request = 1; | ||||||||||
PexResponse pex_response = 2; | ||||||||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Suggested change
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Thanks, I wonder if we should reserve 1, 2, 3, and 4 and have 5 and 6 for the new pex_request/pex_response? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is something proto breaking if you rename it? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It is a breaking change to the generated code, but as long as the structural type doesn't change it's wire-compatible. The main reason to reserve old field tags is for wire-compatibility. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I didn't actually look at the history prior to this diff. I think it's generally a good idea to never reuse a field tag. A common trick is to keep a The temptation to try to keep the numbering compact and visually ordered is understandable, but probably not worthwhile: The intent of explicit field tags is so that newer messages don't blow up older software (they will simply ignore the unknown tags) and older messages can still be read by newer software. The "reserved" syntax just helps the proto compiler prevent us from re-using them. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. what are your thoughts on versioning the proto files? seems like this could be a good first use case for this? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
I'm ambivalent about versioning the file. I don't really see what problems adding another version marker would solve. If we break the wire format, we'll have to update the software version anyway, and if we don't break the wire format, then the existing software should continue to work without changes. That's the original reason for the schema language having explicit field tags. Of course, we might add new fields and need to update the software to take advantage of them, but at that point the version the client cares about is the version of the service it's talking to, not the schema file. IMO wire-format changes are the only ones that matter. Even if the generated code changes, old versions of the library should continue to work as well as they ever did. If we want to change how the service interprets old messages (e.g., we cut out some feature and start reporting errors) then the client has to update because the service version changed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ok I made some updates to this file. It seems like you can't use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The field tags inside a sum are in the same namespace as the enclosing message, so you can simply put the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. ok thanks! |
||||||||||
PexRequestV2 pex_request_v2 = 3; | ||||||||||
PexResponseV2 pex_response_v2 = 4; | ||||||||||
} | ||||||||||
} |
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 recommend marking the removed field tags as reserved so we don't try to reuse them later.