Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Design the reactive event handler architecture #10

Open
saskenuba opened this issue Jan 29, 2021 · 1 comment
Open

Design the reactive event handler architecture #10

saskenuba opened this issue Jan 29, 2021 · 1 comment
Assignees
Labels

Comments

@saskenuba
Copy link
Owner

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 and Serenity

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!

@saskenuba saskenuba self-assigned this Jan 29, 2021
@Nexure
Copy link
Contributor

Nexure commented Feb 1, 2021

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants