Will need to:

• send a message
• send a command (ban/unban, mute, etc)

An action that will wait a specified duration of time. Since seconds will matter then this should use something besides Thread.sleep.

ActionServiceFactory will need to return a consistent type.
There must be type checking in the Action since this is dynamic / known only at runtime

Instead of having (mutable) actions that may/may-not need to ever run (e.g., JPA entities combined with logic), we should separate it out so that we have a container instead.

Action:

• has data on what it is (clientType, and other data; e.g. a SceneItemVisibilityAction has OBS client type, and has data on scene name, scene-item name, and that it should be shown (instead of hidden)
• can be mutated / persisted to Hibernate etc. / is JPA entity

RunnableAction:

• has a copy of the data in the action, except for clientType; instead of client type, has the actual instance of the Client it needs
• has a copy of the CommandRequestContext; e.g. data about who is executing, arguments, etc.
• is runnable; implements how it should use the client
• Immutable; will be executed, must be thread-safe

We could then create a Factory that takes a (mutable) Action and CommandRequestContext and creates a runnable version for the specific request context.

• It would create an immutable clone of the Action (as the Action provided may likely be mutable considering it will come from Hibernate / be JPA compliant)
• It would have a dependency on ActionClientFactory so it can find the right client to inject given the Action's type.

Setting up authentication for the Twitch client can be a PIA.
So, we should provide a guided process to make this easier.

Chat message parser will take a given string and return a parse result containing a command name and list of args.

The parser can be configured to only parse the first char, or the entire message.

WHAT IF
Viewers could submit a command, and for each command OBS would show a scene or scene-item in response unique to each request?

E.g., maybe we have a "clap" command. Each viewer would send the !clap command and a gif (or realistically, a reference to an existing scene with sounds, maybe a text source, etc.) would be rendered at a random position and rotation on the current scene? And then after a specified amount of time, that resource would be cleaned up / deleted from the current scene?

Some caveats might be to specify a limit on how many objects to render (with a reasonable default), so the stream quality doesn't degrade due to too many things running at once.

This would be super neat!

The request bus will contain incoming requests for commands to be executed. These requests will then be dispatched to the Action bus for processing.

But to get there, we need to know what the actual command user are.

So, we need to revisit this and add equality stuff for Command and User as well.

Interface should allow for:

• submitting requests
• pausing
• resuming

Implementation can accept any ExecutorService, but preferably a bounded ThreadPool with a high number of threads since the operations are I/O (not CPU) intensive.

Number of threads should be configurable by the streamer; they may choose to use a default but may lower or raise it depending on the performance of their PC (which would also be running OBS and whatever game they're streaming)

Need to be able to check for command equality in order for cycle detection to work.

Command are unique by name

Takes a command object and gets a flattened list of actions, using the ActionSequencer to request the appropriate sequence.
It should only be getting the list of actions; it shouldn't be injecting execution context or making immutable clones
It must check for recursion / stack overflow; i.e. in the case where an action is to execute a command, and through the chain we end up back at the original command.

Refer to https://github.com/Palakis/obs-websocket/blob/4.x-current/docs/generated/protocol.md#requests

Feeling like I have a rough idea of how to configure a client. However, I feel like there's a gap in my understanding in how the client will be able to receive/broadcast messages currently.

So, let's take a break and dive into concurrency and multithreading -- then if necessary dive into scheduling/queueing in Spring / how to best architect this. Questions I have:

• How will I queue message-send requests?
• How will I handle responses from OBS? How will I know how to route those requests so they go back to the requester?
• How will I respond to the client connecting/disconnecting? E.G., how could I make it possible to manually enable/disable the connection, or to automatically attempt a reconnect? Would it be through emitting an event and consuming it somewhere?

It should still be responsible for providing the next sequence of actions for a given command, and for checking for cyclical actions.

But we may need to look at what it is building to see if it's compatible with the new stuff.

https://github.com/Palakis/obs-websocket/blob/4.x-current/docs/generated/protocol.md#setsceneitemrender

We have a classic example, now we need to have a Spring example and explore how we can keep that configurable and clean.

One question I have is if the Spring example can be done in such a way that the client config can be done in a separate module and brought in as a project dependency. This seems to be the case with AnnotatedEndpointConnectionManager as described in https://spring.io/blog/2013/05/23/spring-framework-4-0-m1-websocket-support but that article is 7 years old.

Anyway, if that's possible then it should be feasible to offer a JSR-356 WS client for OBS that is thoroughly tested / testable as an alternative to the other Java client out there (that is coupled to using the Jetty client implementation specifically, and doesn't offer its main client class as an interface so folks can stub it in their projects/tests)

The program should be able to handle not being able to connect to OBS, Twitch, etc. and try again later. . . Or at the very least, not need to spin up all those services on startup until requested. (maybe we can add configuration for this, so some services always startup while others don't)

CommandExecutorService is responsible for:

• storing the Request timeout
• storing the pause timeout
• returning new instances of SequentialExecutor
• running Requests (and since it should extend ExecutorService, it must validate the Runnable is a Request object, and cast it)

Mutable
has a name and list of actions
can be disabled

Will be used to generate a list of (mutable, Runnable) actions for executor

No good reason to have a separate parent pom anymore

Actions need to be able to get a current reference to the service they use (OBS, Twitch, etc).

This could be done by:

• Action is injected with ActionServiceFactory (has a getService(ActionType type) method
• Action internally has an ActionType (enum with values OBS, TWITCH_CHAT, etc)
• Let's keep it simple for now but consider the possibility later of adding many OBS services or many TWITCH references; could be possible to reference the service by its id or name instead in the service lookup??

Failure modes:

• cannot connect to IRC server
• wrong credentials
• cannot join streamer's channel

There are certain things common to every action, these need to be pulled up into the common interface and possibly implemented with an AbstractAction

• message to send when joining chat (or not at all)
• whether to parse all of message for ! trigger, or just the beginning
• channel to join (streamer's channel)
• who to join as
• server, port, ssl
• listener

A CommandRequest is a group of Actions that will be executed with a single-thread threadpool. It implements Runnable and will be submitted to an Executor (most likely a bounded thread pool with of moderate-to-large size)

Since we don't want to expect the client to have to provide the threadpool instance for each, then we should also provide a factory that will have a method to generate the request from a list of actions (and will inject the threadpool into the commandRequest).

Refer to https://github.com/Palakis/obs-websocket/blob/4.x-current/docs/generated/protocol.md#authentication

Since an action can be to execute a command, it should be possible to detect or to prevent a loop

Needs to connect to Twitch's chat API and listen for messages
Needs to be able to send messages to chat

When doing end-to-end testing with OBS, we'll need:

• default scene collection, with the testing scenes, sources, etc.
• plugins, such as obs-remote

For now creds are being passed as environment variables; this will eventually be stored in the DB as an encrypted string. This should be pulled from there instead.

ALSO, disable the logs that are printing out the raw IRC event stuff, as it includes the password being printed in plaintext to the logs.

Action should refer to a Command

Needs to be accounted for in the ActionEnumerator

Pet the exceptions in a central place and give each a unique code so that these can be passed up to the UI when needed.

• How does it work?
• What clients are available?
• How (and what) can I test?

Now that the project is Spring integrated, take some of the inpromptu sanity-checks in App.java and turn them into Integration tests

See https://stackoverflow.com/questions/2153663/controlling-task-execution-order-with-executorservice for a starting example

There are several improvements to make:

• Pull out internal classes
• Pull out shared volatile Map
• Unit test it
• Integration test it
• Possibly couple to the CommandExecutionContext

When a new message comes in:

• It should be checked for a command trigger (!). This could be in the middle or beginning
• It should be repackaged as an ActionContext containing:
  • command name
  • args
  • User info (username, etc.)
• Should handle if a command doesn't exist for the specified name; whether to respond or not should be configurable (some streamers may want a helpful message, others may want nothing at all because this could be spammy in large streams)

Add logging framework to the project

A CommandExecutionContext defines the key for Action execution within the keyed FIFO executor. It should include:

• command id
• user id
• arguments (list of strings)

I think there's libraries out there that will replace the manual stuff with better messaging? Take a look and see if it would be worth adding the dependency, versus doing what we've been doing and just throwing an IllegalArgumentException

Dispatchers will handle incoming requests for commands. They can be from:

• text chat
• local client (invoking commands directly)

Their job is to build a Command Request and send it to the request bus.

Should be able to execute a command with arguments, for example:

!cheer @person some message
!silence @person 15 min
!grant @person permission
!creategroup groupname @member1 @member2 @member3
!schedule commandname in 45 sec