-
Notifications
You must be signed in to change notification settings - Fork 75
change interfaces for the security-in-multiaddr change #215
base: master
Are you sure you want to change the base?
Changes from all 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 |
---|---|---|
|
@@ -75,10 +75,10 @@ type Transport interface { | |
// Listen listens on the passed multiaddr. | ||
Listen(laddr ma.Multiaddr) (Listener, error) | ||
|
||
// Protocol returns the set of protocols handled by this transport. | ||
// | ||
// Protocols returns the set of protocols handled by this transport. | ||
// If protocols A and B are returned, this means that this transport supports running B on top of A. | ||
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 this a semantic change, or was the previous interpretation supposed to be stacked too? 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. Oh wait, I just read the PR description. I think we will find this interface limiting, and suggest something more sophisticated. [][]protocol.ID could be an option, but we might want to go with a struct for more developer friendliness. 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. That’s correct, it is a semantic change (as I’ve noted in the PR description). None of our transports ever returned more than one value here though. 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. Just read your 2nd comment after posting my reply. We could define a One example where returning multiple protocols might be useful is when we mint a new code point for a new QUIC version. On the other hand, one might argue that if two code points are warranted, the differences between the two transports are probably large enough to just initializing two objects. 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. That would be more self-descriptive, yes. Not sure if ProtocolStack is the right term -- since in the past we've talked about libp2p being a factory of stacks with different characteristics and API shapes/semantics (e.g. message orientation). So that might get overloaded in the future. Perhaps ProtocolSeq? 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. Also, the term "stack" to me denotes some kind of behaviour associated with that type, versus choosing a keyword for a type with the very limited purpose of enabling AND and OR combinations of protocols IDs. |
||
// See the Network interface for an explanation of how this is used. | ||
Protocols() []int | ||
Protocols() []ma.Protocol | ||
|
||
// Proxy returns true if this is a proxy transport. | ||
// | ||
|
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.
The reason we use a different import alias is to differentiate from the Go SDK crypto. I don't have strong opinions either way, just noting it.