Documentation ¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type Client ¶
type Client struct { // The time we're willing to wait to receive a response from the server. ResponseTimeout time.Duration IncomingEvents chan interface{} IncomingResponses chan *opcodes.RequestResponse Opcodes chan opcodes.Opcode Log Logger }
Client represents a requests client to the OBS websocket server. Its intention is to provide a means of communication between the top-level client and the category-level clients, so while its fields are exported, they should be of no interest to consumers of this library.
func (*Client) SendRequest ¶
SendRequest abstracts the logic every subclient uses to send a request and receive the corresponding response.
To get the response for a sent request, we can just read the next response from our channel. This works fine in a single-threaded context, and the message IDs of both the sent request and response should match. In a concurrent context, this isn't necessarily true, but since gorilla/websocket doesn't handle concurrency (it'll panic; see https://github.com/gorilla/websocket/issues/119), who cares?
Technically a request ID and response ID mismatch could happen if the server processes requests in a different order it received them (e.g. we should 1, then 2; but it processes 2, and then 1), then yeah... there'll be an error. We could add a mutex wrapping sending our request and reading from the channel, but I personally haven't experienced this yet, so
It should be noted multiple connections to the server are totally fine. Phrased differently, mesasge IDs are unique per client. Moreover, events will be broadcast to every client.
type Logger ¶
type Logger interface{ Printf(string, ...interface{}) }
Logger is a interface compatible with both the stdlib's logger and some third-party loggers.
type LoggerWithWrite ¶
LoggerWithWrite helps us anonymously satisfy a Writer interface