-
Notifications
You must be signed in to change notification settings - Fork 656
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # 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.