[PSR-14] Meeting Summary - 2018-08-30 (ACTION REQUIRED!)

[Larry Garfield]

We had another energetic call today. At this point we're arguing about
minutia and details, which I take as a good sign. Highlights include:

* We're going to rename StoppableTaskInterface::isStopped() to
isPropagationStopped(), since that's what both Symfony and Zend Framework call
it now.

* Cees-Jan showed a React Promises-based proof of concept. By and large it
looks like the spec is compatible with that workflow as is with no need for
further revision. See: https://github.com/WyriHaximus/php-broadcast

* We discussed performance considerations, especially prompted from discussion
with the Doctrine team who have concerns about event handling at extreme
scale. Larry has added benchmarks to his implementation that suggest
performance should be more than fine. We will continue to monitor the
performance question though and make sure there's no unexpected gotchas.

* We spent quite a bit of time discussing the fate of the Message vs Task use
cases. In practice, the Message is essentially a command bus. Task is what
nearly all PHP libraries today call Events, even if that is academically
inaccurate. We're OK with that, and I'll be adding more clarity on that to
the spec or metadoc. While they overlap considerably, they also do have
different use cases. Are they enough that we should split the spec in two?
Or that we should keep a unified spec but split up the packages? We're not
sure, and we want to get input from others. (That means you, reading this, we
want your input!)

**PLEASE TAKE A MOMENT FOR THE BRIEF ASK BELOW**

I've put together a very quick survey we'd like to have people respond to to
help gather input on that point. This is *not a vote*, it's a non-binding
survey for feedback. We actively want feedback from everyone, whether you're
a "formal" member of FIG or not. Please take 30 seconds to respond to the
following survey within the next week or so.

https://docs.google.com/forms/d/1fvhYUH6xvPgJ1UW9I-3pMGPUtxkt5_Ph6_x_3qXHIuM/
viewform

--Larry Garfield
PSR-14 Editor

[Daniel Plainview]

> In practice, the Message is essentially a command bus.

This is kinda inaccurate language when you say that "message" is a "bus"...

But more importantly, message can be either command or event: why do you make accent on "command" bus?

Command bus MAY return something (it doesn't violate CQRS: https://vladikk.com/2017/03/20/tackling-complexity-in-cqrs/; CQRS is about write and read models [look at the definition]; it's a widespread fallacy that CQRS says something about what method should return or not) from the command handler; on other hand, event bus is not able to do this.

I suggest to do not use abstract "message" word: commands and events are both events, but they can be handle way differently.

[Daniel Plainview]

>  commands and events are both events

are both messages*