This will require a lot of thinking - and there's two approaches I can see us taking.
First, we can just let the user manage everything. Pass them a raw socket/stream and let them handle the rest - however this can be a lot of code for simple operations.
The method I want to proceed with is writing a whole API for real-time protocols, like our current API for request protocols.
- Should this be a separate package? Most of our concepts that apply to a request server do not apply to generic real-time protocols.
- How do we store and manage connections?
- How do we manage authentication?
- How will this tie into Bunkum in general? In other words, how will the request server (Bunkum in its current form) hand off a connection to the real-time server?
Example use-cases that need to be filled by this:
- Real-time activity stream and notifications in Refresh via WebSockets
- A chat application that sends/receives messages and events through a WebSocket
- A custom server for osu! that uses binary data over TCP to communicate
If we end up making the API, we should try to generalize this so the same code can be re-used for multiple protocols, similar to how we manage protocols for the request server.
This will require a lot of thinking - and there's two approaches I can see us taking.
First, we can just let the user manage everything. Pass them a raw socket/stream and let them handle the rest - however this can be a lot of code for simple operations.
The method I want to proceed with is writing a whole API for real-time protocols, like our current API for request protocols.
Example use-cases that need to be filled by this:
If we end up making the API, we should try to generalize this so the same code can be re-used for multiple protocols, similar to how we manage protocols for the request server.