aws_websocket_convert_to_midchannel_handler()

[graebm]

Implementation isn't 100% complete. Doesn't yet handle messages in the READ direction, only in the WRITE direction.

Note that refcounting has been removed from websocket.

/**
 * Convert the websocket into a mid-channel handler.
 * The websocket will stop being usable via its public API and become just another handler in the channel.
 * The caller will likely install a channel handler to the right.
 * This must not be called in the middle of an incoming frame (between "frame begin" and "frame complete" callbacks).
 * This MUST be called from the websocket's thread.
 *
 * If successful, the channel that the websocket belongs to is returned and:
 * - The websocket will ignore all further calls to aws_websocket_X() functions.
 * - The websocket will no longer invoke any "incoming frame" callbacks.
 * - There is no need to invoke aws_websocket_release(), the websocket will be destroyed when the channel is destroyed.
 *   The caller should acquire a hold on the channel if they need to prevent its destruction.
 * - aws_io_messages written by a downstream handler will be wrapped in binary data frames and sent upstream.
 *   The data may be split/combined as it is sent along.
 * - aws_io_messages read from upstream handlers will be scanned for binary data frames.
 *   The payloads of these frames will be sent downstream.
 *   The payloads may be split/combined as they are sent along.
 * - An incoming close frame will automatically result in channel-shutdown.
 *
 * If unsuccessful, NULL is returned and the websocket is unchanged.
 */
AWS_HTTP_API
struct aws_channel *aws_websocket_convert_to_midchannel_handler(struct aws_websocket *websocket);

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[JonathanHenson]

talked offline, I think the constructor shouldn't be doing the channel operations like this, and we should at least break the orchestration up between functions. Your call though.

[graebm]

Agreed that this does not separate concerns, but given how the channel API works, it was the most RAII way of doing things I could come up with, where the thing returned from the function is ready to go, and if there's an error then things end up in the same state they started.

The Channel API could really use a revision pass that makes a clean setup possible.