Design the reactive event handler architecture
saskenuba opened this issue · comments
Now that the client is somewhat structured, we can start to think about how messages coming from Steam should propagate through the client, in a way the end-user can interact with them.
While searching for references, two libraries reactive libraries come to mind:
Teloxide code is rather intricate, and I not sure I follow it completely.
Serenity is ok.
The event dispatcher:
The user could register "channels" that he is interested, such as SteamFriends(friends messages, friends persona status changes), or SteamUser(logOn, logOff).
This is what SteamKit2 does, and what message goes to which channel is kind arbitrary.
Then, the user can send outgoing messages, or answer to incoming ones based on his callbacks.
The basic flow would be the following, excluding the initial communication and heartbeat:
inc. socket message -> to packet message -> check if handler exists || -> no -> discarded
\
-> yes -> user callback -> message written on socket
We are open to new ideas!
While I have to look through more of Teloxide, I do know of and have used serenity before. While using serenity, I do like how they they allow you to register an event handler in some parts, to allow you to listen to events from discord. While for other parts, such as here they let you register commands as functions, and group them together using macros, along with attaching permissions, though this may not require such grouping, or maybe so if your listening to chat events, I still do love the system that they use.
As for other callbacks, one of my suggestions would be while, still allowing users to register callbacks to listen to socket events, another cool feature would be to have the client await the callback and return the response directly after calling the functions, if they so choose to include that feature. This would stop people from having to wait and handle it in the callback, like in SteamKit2, where they have to await after the function.