[PSR-14] Meeting Summary - 2018-08-02

[Larry Garfield]

We had an incredibly productive call today! I'm really happy with how things are shaping up. We also renamed everything. :-) Hopefully it won't confuse people too much.

* We're going to remove the boolean flag from stopPropagation(). It's a stop, there's no unstop option.
* For error handling in the notify case, the spec will explicitly specify that the dispatcher MUST NOT let throwables from one listener prevent another listener from running.
* For error handling in the modify case, there are ample use cases where a listener failure should block future listeners. Therefore that will be expected, and how a dispatcher handles that case is up to it. (Let it bubble, wrap it in another exception, trigger another event, etc.) However, if it decides to communicate it to another system (wrapped exception, new internal event, etc.) we'll provide an interface it MUST include on the object in order to standardize getting basic debug information, like what event triggered the error.
* And finally, naming things. We renamed almost everything in this meeting. :-) The new naming structure we're looking at is dividing the world into "messages" (the "notify" case) and "tasks" (the "modify" case).

EventInterface (empty marker)
MessageInterface extends EventInterface (empty marker)
TaskInterface extends EventInterface (empty marker)
StoppableTaskInterface extends TaskInterface

And then they are handled through a MessageNotifierInterface::notify() method, and a TaskProcessorInterface::process() method. This split has a few advantages:

* It's clear that they're separate pipelines.
* It avoids most existing biases around the word "event".
* It sidesteps nearly all BC issues with existing implementations (to the best of our knowledge).

A side effect, though, is that we have no "dispatcher" anymore. That means the "Event dispatcher spec" is about, er, task processing. :-) To that end, we also propose renaming PSR-14 to "Event Processing and Notification". I don't know if that would require any approval from the CC; it's not really a change in scope but it is a rebrand of sorts. I defer to the Secretaries here.

The next step is building for-realsies implementations. I already have one here:

https://github.com/Crell/Tukio

(It's not updated for the naming changes above but will be as soon as the spec and code package themselves are updated.)

And we should have 2-3 more that group members have built by our next meeting, hopefully. Other members of the public are also *welcome and encouraged* to try building against the current interfaces and offering feedback. I will tag an alpha2 in the event-dispatcher repository once everything is renamed. (Which... probably means that package gets renamed at some point, too, but not yet, to avoid confusion.)

--Larry Garfield
PSR-14 Editor

[Dead Lugosi]

Your friendly neighborhood FIG secretaries see no need to raise a vote for the renaming as the underlying purpose for this PSR has not changed.

--
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 php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/1533241295.2704915.1461643144.41AB2435%40webmail.messagingengine.com.
For more options, visit https://groups.google.com/d/optout.