Provide guidance on when to use Messages vs Tasks #1070
Conversation
proposed/event-dispatcher-meta.md
Outdated
| | Must be serializable | May be serializable | ||
| | May be delayed | Must be processed immediately | ||
| | Listener order not guaranteed | Listener order is guaranteed | ||
| | All listeners will fire | Listeners may short-circuit the pipeline |
There was a problem hiding this comment.
May short-circuit the pipeline IF AND ONLY IF the stoppable task interface was used for the task provided.
Crell
changed the title
proposed/event-dispatcher-meta.md
Outdated
|
|
||
| A Task Processor is appropriate when: | ||
|
|
||
| * The event is being used as a "hook" or "pointcut" to extent or modify the Emitter's behavior. |
proposed/event-dispatcher-meta.md
Outdated
|
|
||
| * The event is being used as a "hook" or "pointcut" to extent or modify the Emitter's behavior. | ||
| * The Emitter wishes to allow listeners to interact with each other (through mutating the event). | ||
| * NEED A 3RD EXAMPLE HERE. |
There was a problem hiding this comment.
Maybe... those first two (especially the first) were great.
There was a problem hiding this comment.
Sure, but IMO we should have 3 for each, to make it clear that they're both legit. 😄 I like parallelism.
proposed/event-dispatcher-meta.md
Outdated
|
|
||
| * The event is being used as a "hook" or "pointcut" to extend or modify the Emitter's behavior. | ||
| * The Emitter wishes to allow listeners to interact with each other (through mutating the event). | ||
| * NEED A 3RD EXAMPLE HERE. |
There was a problem hiding this comment.
How about: "The emitter chooses to delegate when processing is complete to the listeners."
proposed/event-dispatcher-meta.md
Outdated
|
|
||
| | Messages | Tasks | ||
| |-------------------------------|------------------------------- | ||
| | Must be immutable | May me mutable |
proposed/event-dispatcher-meta.md
Outdated
| |-------------------------------|------------------------------- | ||
| | Must be immutable | May me mutable | ||
| | Must be serializable | May be serializable | ||
| | May be delayed | Must be processed immediately |
There was a problem hiding this comment.
I'm not entirely convinced that tasks must be processed immediately. As @WyriHaximus demonstrated last week, a Task could compose one or more promises, which the listeners either create or react to. As such, processing could be delayed in them as well.
There was a problem hiding this comment.
True; although in that case I would argue that the listener is processing the event by enqueuing the async action.
Perhaps "listeners must be called immediately" (even if the listener then does something async)?
proposed/event-dispatcher-meta.md
Outdated
| | Must be immutable | May me mutable | ||
| | Must be serializable | May be serializable | ||
| | May be delayed | Must be processed immediately | ||
| | Listener order not guaranteed | Listener order is guaranteed |
There was a problem hiding this comment.
Listener order is a product of the listener provider, not the notifier or the task processor; they simply iterate the listeners. As such, I'm not sure we should bring it up here.
There was a problem hiding this comment.
A notifier may do something like fork or use pthreads to handle different listeners, which means the order is non-deterministic. Task order must be determinstic.
proposed/event-dispatcher-meta.md
Outdated
|
|
||
| As a general guideline, a Message Notifier is appropriate when: | ||
|
|
||
| * The Emitter does not care what responses are taken to an event. |
There was a problem hiding this comment.
I think we should rephrase this to:
The Emitter does not care what actions listeners take in response to an event.
Unless this is implying the emitter does not check the event state on each iteration. In which case:
The Emitter will not check event state after each listener.
There was a problem hiding this comment.
It means both; it doesn't care and it won't check. I've changed it to your first suggestion.
No description provided.