Added support for an optional connection up/down buffered channel to the client. #174
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
If the caller wants to be notified every time the client detects a change in the Connected/Disconnected state for the websocket (from the last known state), it should create a buffered channel of boolean, specifying the depth for the buffered channel. Then, it should pass this value in the clients Options fields. When the Client connects for the web socket, it knows it's last known state. If it is unable to connect and the last know state was connected, it updates it's last know state to disconnected. If the options Buffered channel is set, it will send a False (disconnected) message on the buffered channel. If it is able to connect the websocket and read messages, if the last known state was disconnected, it changes it to connected. If the options Buffered channel is set, it will send a True (connected) message on the buffered channel. The caller (running on a different goroutine), is responsible for retrieving any messages from the buffered channel. (Only set it if you will retrieve these messages). When the caller Closes the client, the client will cleanup and set it's Options buffered channel reference to nil. (This lets the garbage collector know the client is no longer using it). The caller should wait for the Close to complete. It is up to the caller to decide if it wants to read any buffered channel messages after calling Close. The idea behind this is many telephony applications want to know when they can communicate/control calls with Asterisk. If the connection is down, an application can change it's internal state machine to know it can't communicate with Asterisk. This allows them to notify someone of a problem. Potentially switch to a different Asterisk for call control.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
If the caller wants to be notified every time the client detects a change in the Connected/Disconnected state for the websocket (from the last known state), it should create a buffered channel of boolean, specifying the depth for the buffered channel.
It can then pass this value in the clients Options fields.
When the Client connects for the web socket, it knows its last known connected/disconnected state.
The caller (running on a different goroutine), is responsible for retrieving any messages from the buffered channel. (Only set it if you will retrieve these messages).
When the caller Closes the client, the client will cleanup and set it's Options buffered channel reference to nil. (This lets the garbage collector know the client is no longer using it).
The caller should wait for the Close to complete. It is up to the caller to decide if it wants to read any buffered channel messages after calling Close.
The idea behind this is many telephony applications need to know when they can communicate/control calls with Asterisk. If the connection is down, an application can change it's internal state machine to know it can't communicate with Asterisk. This allows them to notify someone of a problem. Potentially switch to a different Asterisk for call control. Many more possibilities.
Additionally, added 3 more fields to the BridgeData (CreationTime, VideoMode, and VideoSourceID).
This change is