-
Notifications
You must be signed in to change notification settings - Fork 656
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
Add some docs to note on which message types a bootstrapped Channel w… #207
Conversation
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.
Just a few nits here.
Sources/NIO/Bootstrap.swift
Outdated
/// The returned `ServerSocketChannel` by `bind` is the server channel and will fire the accepted `SocketChannel`s through the `ChannelPipeline` via `fireChannelRead` | ||
/// and so operate on `Channel` as inbound messages. Outbound messages are not supported by `ServerSocketChannel`, which means each write attempt will be failed. | ||
/// | ||
/// The accepted `SocketChannel` will operate on `ByteBuffer` as inbound and `IOData` as outbound messages. |
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.
Let's change this to: "The EventLoopFuture
returned by bind
will fire with a ServerSocketChannel
. This is the channel that owns the listening socket. Each time it accepts a new connection it will fire a SocketChannel
through the ChannelPipeline
via fireChannelRead
: as a result, the ServerSocketChannel
operates on SocketChannel
s as inbound messages. Outbound messages are not supported on a ServerSocketChannel
which means that each write attempt will fail.
Accepted SocketChannel
s operate on ByteBuffer
as inbound data, and IOData
as outbound data."
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.
@Lukasa I think we should still say: as a result, the ServerSocketChannel
operates on Channel
s as inbound messages...
SocketChannel
is not public so it may be confusing otherwise if the user tries to use it as InboundIn
and can't. WDYT ?
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.
Sure, that's fine.
Sources/NIO/Bootstrap.swift
Outdated
@@ -410,6 +421,7 @@ public final class ClientBootstrap { | |||
/// try channel.closeFuture.wait() // Wait until the channel un-binds. | |||
/// ``` | |||
/// | |||
/// The `DatagramChannel` will operate on `AddressEnevelope<ByteBuffer>` as inbound and outbound messages. |
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.
AddressedEnvelope
.
971d0c6
to
04b8003
Compare
@Lukasa PTAL again |
Sources/NIO/Bootstrap.swift
Outdated
/// the `ServerSocketChannel` operates on `Channel`s as inbound messages. Outbound messages are not supported on a `ServerSocketChannel` | ||
/// which means that each write attempt will fail. | ||
/// | ||
/// Accepted `SocketChannel`s operate on `ByteBuffer` as inbound data, and IOData as outbound data. |
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.
Backticks around IOData
.
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.
fixed
…ill operate. Motivation: It's not clear to a user which inbound / outbound messages is expected for the different Channel implementations. This can result into wrong code and confused users. Modifications: Add some docs to explain which messages are supported / expected by the different Channels that can be bootstrapped. Result: More clear docs.
a33dda4
to
d2f19f2
Compare
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.
Please rebase, then merge when the tests go green.
Motivation: Now that Swift 5.9 is GM we should update the supported versions and remove 5.6 Modifications: * Update `Package.swift` * Remove `#if swift(>=5.7)` guards * Delete the 5.6 docker compose file and make a 5.10 one * Update docs Result: Remove support for Swift 5.6, add 5.10
…ill operate.
Motivation:
It's not clear to a user which inbound / outbound messages is expected for the different Channel implementations. This can result into wrong code and confused users.
Modifications:
Add some docs to explain which messages are supported / expected by the different Channels that can be bootstrapped.
Result:
More clear docs.