So I am thinking about to do a big change in event thing. Currently there is an eventable consumer which emits a consumer cycle event. The listeners listen to this event and do the limiting logic on this event (before heading to the next cycle). Also, this event contained the consumer instance, so it could shut it down for example if command count reached a limit. This was necessary because consumer is basically a loop, so to stop it you must hold an instance of it.
What I am thinking about now: Make the listeners hold the consumer and rely on existing command events: received, executed, failed. This has one big advantage: removes the need for eventable consumer since the event logic is completely moved to the event middleware.
So I am thinking about to do a big change in event thing. Currently there is an eventable consumer which emits a consumer cycle event. The listeners listen to this event and do the limiting logic on this event (before heading to the next cycle). Also, this event contained the consumer instance, so it could shut it down for example if command count reached a limit. This was necessary because consumer is basically a loop, so to stop it you must hold an instance of it.
What I am thinking about now: Make the listeners hold the consumer and rely on existing command events: received, executed, failed. This has one big advantage: removes the need for eventable consumer since the event logic is completely moved to the event middleware.
What do you think? /cc @rosstuck