The development of my multi-threaded moderation bot in Java has ground to a halt . The part that automatically filters unwanted messages is almost done. I don’t intend to favor (or possibly even support) mod commands for filter settings, so instead I need a web interface/dashboard.
Although web development is not my strong suite, I think I could pull of some sort of form where authenticated users alters a setting and the bot changes accordingly (e.g. change the maximum allowed capital letters to 12).
However, beyond this I need two-way, asynchronous communication between the bot and any web user. At its core, its a web-based chat where the moderators can send timeouts. My need for this is irrelevant as this point. This involves the bot sending chat messages to specific web users, and web users sending manual timeouts back to the bot. The bot would work as an intermediate to the channel on IRC.
The only applicable solution I have found so far is websockets, but the required third-party libraries (like glassfish or tyrus) have a server model focusing on only responding to client requests. My attempts at adapting this so that the server/bot can send unrequested messages are functional, but are in no way a pretty sight. Specifically, this is because the library implementations of client endpoints are instantiated through annotations, and therefore cannot be given shared resources for multi-threaded communication (like a BlockingQueue) without involving ugly, static variables. I feel that there should be a better solution for unhindered communication between an application and the web.
Spring Boot might be your answer, you can generate the skeleton web application with websocket support using a generator like https://start.spring.io/ or https://jhipster.github.io/
Thank you, I will see if this the answer I need and get back to you.
Edit: I’m really out on my deep end here, but research so far indicates Spring Boot is also request-driven - in the sense that the server handles several requests and returns a result asynchronously/synchronously. I want a model where the server broadcasts messages at its own accord, and users sometimes sending messages where a response is not needed. This is more akin of the observer pattern. If I need to forcibly adapt Spring Boot to do this as well, I am better off continuing with Tyrus.
If you could outline a bit more specifically how Spring Boot can do this from the get go, I’m all ears.
Yeah, isn’t that something like for example a chat server? where you post a message not expecting a result and the message gets broadcasted to all the participants in the room?
Yes, but even though the server doesn’t respond to only you, it is only reactive in nature. All frameworks for websockets seem to be designed with this intent, even though websockets are designed to be full duplex with no restrictions on who sends the first message.
To allow the server to broadcast on its own terms, my best bet so far seem to be to use one of these frameworks in a Comet model. The client-side script would continually and asynchronously request a new message from the twitch channel, and the server would respond only once there is one.
While drowning in articles of all the different Web solutions out there, I’ve decided to work with what I know - somehow interface a Tyrus server with websockets into my bot. Web clients will connect in a sort of Publish-Subscribe pattern where they subscribe to the messages of a particular channel. A seperate thread will hold all the clients and distribute the messages to the right recipients as they come.
My biggest obstacle will be working against the framework’s all annotations and factories designed for my “convenience”, but I’ll sort it out. Thanks for the help!
I’ve created my own Pub-Sub system on websockets (written in Go which is amazing for working with highly concurrent stuff), it’s pretty bad, took way too much time, but it sort of gets the job done - as of my current needs.
The largest problem with my solution is that I have to do a ton of security stuff myself if the application is supposed to become publicly hosted. And I don’t think I’ve got the competence for that.
That sounds tempting. From what I can see Go doesn’t overcomplicate Websockets that much, and the language itself looks easy enough to pick up. I started out with C++ and they seem to share some common ground.
I’m working on a TMI connection library in Go, it needs some polish but it’s pretty OK.
Looks great to me! And this is definitely needed. Beginners and advanced users alike should be able to build without worrying about the intricacies of TMI.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.