On Fri, Mar 1, 2019 at 2:40 PM <[email protected]> wrote: > I've been thinking should the name of the package (and consequently, the > interfaces) not be something like "MessageDispatcher"? This is a bit more > generic and could cover messages, events and commands. >
For a long period of time, we were working with having both an EventDispatcher and a MessageDispatcher. However, on looking at the various use cases, we decided to narrow the focus to only the EventDispatcher. There are two general styles of message dispatchers. One is for queueing, and in that case, you have both an object that will enqueue a message, and one that will dequeue messages and dispatch them to workers. When queueing a message, no listeners are involved; it's a 1:1 relationship between the message and the queue. Generally speaking, the same is true when dequeueing messages; only one worker will operate on the provided message. In each case, the message MUST be immutable to guarantee the ability to replay the queue. Both cases are very different use cases to the EventDispatcher we have specified, which posits a 1:N relationship between events and listeners. The other type of message dispatcher can be seen in components such as symfony/messenger. On the surface, it looks quite similar. However, in practice, it's quite different: it acts like a command bus. Command buses are very different from the specification we set out to develop. They posit: - immutable commands, which are passed to - a bus that executes middleware that can decorate the command (i.e., acts a bit like a filter chain, with each operating on the return value of the previous), and - match the command to a single handler, which it then - invokes, and thus executes the command. The EventDispatcher as we have specified does not satisfy these criteria. You CAN use immutable instances, but we require the SAME instance be passed to each listener (i.e., no decoration allowed). We allow halting execution before all listeners are executed if the event indicates no further processing is required/possible (command buses generally only allow that via exceptions). Order of listener execution is determined by the _provider_ given to the event dispatcher, and there is no differentiation between listeners; they all have the same signature (no differentiation of concepts such as "middleware" or "handlers"). To be honest, PSR-15 is much closer to a command bus than this specification, albeit an HTTP-specific variant. Interestingly, I think both a generic subject/observer pattern (which is close to the idea of a message notifier) and a command bus CAN be expressed and implemented using this specification as degenerate cases (we allow immutable objects; priority can be delegated to a provider, which can in turn do something akin to matching an event to a pipeline that ends in a "handler"; the "command" could be wrapped in an event, which allows the event to ask a an envelope for purposes of decoration/metadata), we specifically do not address these two use cases as we feel they likely need their own specifications, due to the subtle differences in usage and context. > > On Wednesday, February 27, 2019 at 8:02:10 PM UTC+1, Chuck Burgess wrote: >> >> LGTM... my only feedback was my corrections PR -- >> https://github.com/php-fig/fig-standards/pull/1149 >> I'm also good with both of these being applied: >> https://github.com/php-fig/fig-standards/pull/1152 >> https://github.com/php-fig/fig-standards/pull/1153 >> >> CRB >> *about.me/ashnazg <http://about.me/ashnazg>* >> >> >> On Thu, Feb 21, 2019 at 2:33 PM Larry Garfield <[email protected]> >> wrote: >> >>> On Wed, Jan 30, 2019, at 12:31 PM, Cees-Jan Kiewiet wrote: >>> > Yes 27th of February 2019 is the correct deadline. >>> > >>> > On Wed, Jan 30, 2019 at 7:17 PM Girgias <[email protected]> wrote: >>> > > The review period deadline needs to be changed. The 27th of Jan 2019 >>> was two days ago. >>> > > Did you mean 27th of February 2019? >>> > > >>> > > Best regards >>> > > >>> > > George P. Banyard >>> > > >>> > > >>> > > On Wed, 30 Jan 2019 at 19:05, Cees-Jan Kiewiet <[email protected]> >>> wrote: >>> > >> As of today, with a unanimous vote from the working group, we >>> formally begin the REVIEW phase of the proposed PSR-14 (Event Dispatcher) >>> specification. The proposed specification is in the fig-standards >>> repository at the following locations: >>> > >> >>> > >> - Specification: >>> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher.md >>> > >> - Metadocument: >>> https://github.com/php-fig/fig-standards/blob/master/proposed/event-dispatcher-meta.md >>> > >> >>> > >> During the Review phase, acceptable changes to the specification >>> include wording, typographical fixes, and clarifications. If you feel major >>> changes are necessary or have, please bring your arguments/questions to the >>> list under this thread. If any major changes are considered, we will return >>> to the Draft phase. >>> > >> >>> > >> The Review period will end no sooner than 27 Jan 2019 at 11:59pm. >>> At that time, if the working group can demonstrate two viable trial >>> implementations, and no need for major changes, I will call for an >>> Acceptance Vote. >>> > >> >>> > >> Cees-Jan Kiewiet, your friendly neighbourhood PSR-14 Sponsor >>> >>> Core Committee members: How shall the WG interpret your silence? :-) As >>> approval or indifference? >>> >>> If approval, please let us know that you're approving so we know not to >>> worry when it comes time to call a vote. :-) >>> >>> Beuller? >>> >>> --Larry Garfield >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "PHP Framework Interoperability Group" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/php-fig/ac14ce13-e39b-4227-b9d7-68c7ef6bd834%40www.fastmail.com >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- > You received this message because you are subscribed to the Google Groups > "PHP Framework Interoperability Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/php-fig/cbabeda2-7fbf-41a4-a05e-d065aec4e143%40googlegroups.com > <https://groups.google.com/d/msgid/php-fig/cbabeda2-7fbf-41a4-a05e-d065aec4e143%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Matthew Weier O'Phinney [email protected] https://mwop.net/ he/him -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAJp_myVqYDwZGXn%3DHPmNsg48FiTzTdUorS55K-vzjAMv69nXtA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
