-
Notifications
You must be signed in to change notification settings - Fork 7
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
Adopt new bag-of-bytes protocol #55
Conversation
Motivation: The core package added a bag-of-bytes protocol which transports must be generic over. We need to adopt those changes here. Modifications: - Add a `GRPCNIOTransportBytes` type which wraps `ByteBuffer` and implements the `GRPCContiguousBytes` protocol. - Use this as the bytes type for client/server transports. - Update the appropriate state machines to deal in terms of `ByteBuffer` - Update the compressor/decompressor to deal in terms of `ByteBuffer` - Update tests Result: Avoid unconditonal copying of messages to/from `[UInt8]`/`ByteBuffer`
This depends on and won't compile until grpc/grpc-swift#2155 is merged. |
public import NIOCore | ||
|
||
/// The contiguous bytes type used by the gRPC's NIO transport. | ||
public struct GRPCNIOTransportBytes: GRPCContiguousBytes, Hashable, Sendable { |
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.
Do we need to wrap the ByteBuffer
? Can we not conform it to GRPCContiguousBytes
directly? Are we afraid the couple of methods we'd need to declare would clash with some future API added to it?
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.
Wrapping it gives us flexibility to change it in the future without breaking API.
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.
Right - I didn't consider this because this package is already so tied to NIO (and I find it hard to believe we'd replace ByteBuffer on NIO anytime soon 😄). But that's fair.
@@ -105,7 +107,7 @@ extension HTTP2ClientTransport { | |||
self.channel.retryThrottle | |||
} | |||
|
|||
public func connect() async { | |||
public func connect() async throws { |
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.
Is it a regular Swift convention to keep the throws
from the protocol signature if we don't actually throw in the implementation?
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'm not sure if there is a convention. The protocol
is throws
so adding it back isn't an issue and leaves us scope in the future in case the implementation actually needs to become throwing.
Sorry, mistakenly clicked the not a draft anymore button |
Motivation:
The core package added a bag-of-bytes protocol which transports must be generic over. We need to adopt those changes here.
Modifications:
GRPCNIOTransportBytes
type which wrapsByteBuffer
and implements theGRPCContiguousBytes
protocol.ByteBuffer
ByteBuffer
Result:
Avoid unconditonal copying of messages to/from
[UInt8]
/ByteBuffer