Currently dispatch() is a blocking operation. If a plugin receiving an event performs a dispatch or an operation triggering one (for example: updateState() ), the new event message will be transmitted to all of the plugins before the original event is finished being sent to all plugins.
For example, Plugin 1,2, and 3 are loaded and an STATE:DISCONNECTED is received
dispatch STATE:DISCONNECTED
Plugin #1: process STATE:DISCONNECTED
Plugin #2: process STATE:DISCONNECTED
Send command to IRC Server
dispatch COMMAND:...
Plugin #1: process COMMAND
Plugin #2: process COMMAND
Plugin #3: process COMMAND
updateState CONNECTED
dispatch STATE:CONNECTED
Plugin #1: process STATE:CONNECTED
Plugin #2: process STATE:CONNECTED
Plugin #3: process STATE:CONNECTED
Plugin #3: process STATE:DISCONNECTED
From this it's obvious that misordered state messages can cause erroneous plugin behavior, but also of concern is that certain events like COMMAND must be blocking because they can be cancelled.
Either only some of the messages will be queued, or the behavior of commands/blocking operations must be modified so that the Bot does not perform the operations, but requests/sends an event for them to occur.
Currently dispatch() is a blocking operation. If a plugin receiving an event performs a dispatch or an operation triggering one (for example: updateState() ), the new event message will be transmitted to all of the plugins before the original event is finished being sent to all plugins.
For example, Plugin 1,2, and 3 are loaded and an STATE:DISCONNECTED is received
From this it's obvious that misordered state messages can cause erroneous plugin behavior, but also of concern is that certain events like COMMAND must be blocking because they can be cancelled.
Either only some of the messages will be queued, or the behavior of commands/blocking operations must be modified so that the Bot does not perform the operations, but requests/sends an event for them to occur.