RFC Events Core events vs. Userspace Events (wrt event propagation)

[d42ohpaz]

I was looking at the old issue #1480, and it got me thinking: having the core of node use the same events as the userspace puts restrictions on node, specifically with respect to adding in the feature to allow stopping of event propagation.

Now, I understand - and agree - completely that as it stands right now, node should not allow stopping the propagation of events because of these internal dependencies. Here is what I'm suggesting and looking to help out with: separating core-dependent events away from userspace events. What I mean by this is, as suggested in the aforementioned ticket, core sits on the 'end' event in many places. What if we were to emit both the 'end' and a secondary '_end' (or '_core-end', or whatever, it doesn't really matter, as long as it's reasonably distinct) so that both node can get the events it's looking for, and the userspace gets what it's looking for, AND allow supporting the safely stopping of event propagation.

My first thoughts on starting this separation would be to either:

• modify all core calls to .emit to add a second call to emit for the event using an event name specific for the core. This would only require modifying the emission and listening parts of the code (to change event types of the listeners, and to add an additional line of code for the emissions)
• modify events.emit() so that the type can either be a string, or an array of strings. The array of strings would contain the original event type (e.g., 'end', 'close', 'bobs-your-uncle'), and one or more aliases (e.g., 'end-core', 'close-core', 'bobs-your-uncle', etc). This would, in my opinion, be a better solution as you only modify the events.emit() calls to add in the core aliases, instead of having to deal with two nearly identical calls to events.emit(). The changes to the event emitter would only need to be minimally changed to support accepting an array of types.

With that said, I think that allowing the userspace to stop event propagation could be very beneficial. For example, I'm working on a system that has a few layers in logic for dealing with socket communications. Depending on what type of data comes in through the socket will determine where in the code a message should be directed - the other layers don't need to know about these messages at all. It would make things clearer from a development stand-point, as well as "safer" as we wouldn't have to worry about accidentally triggering an error due to a "malformed" packet. Right now we are having to code defensively to ensure that certain communications don't get leaked to our message processors.

Heartbeats are another, more common, example. Pinging two sockets doesn't need to be an application-wide message (it could, but in the spirit of keeping things simple, it doesn't). socket-/engine-io uses heartbeats over the same channel that their normal messages use. As with my previous paragraph, I would have to code defensively to discern whether I need to care about the message, or discard it because it's a ping. If socket-/engine-io could stop propagating the 'message' event on a ping, this problem would be moot, without negatively impacting higher levels of code.

NB, I could be wrong about how socket-/engine-io's customers listen for messages. I'm not suggesting that socket-/engine-io change their behavior. I am merely throwing a hypothetical out there using a popular library.

I also believe that this could help with module development. It would be very easy to accidentally emit an event that steps on the toes of another module; that is to say, module A could be listening for events 'foo', and react in one way, while module Z happens to be listening for events 'foo', and react in a conflicting way. Now, if the module authors could "namespace" their events for their internal use, this problem would be avoided, without sacrificing backward compatibility and/or a feature their customers have come to expect.

Okay, that's enough about that. As the title of the issue suggests, I'm looking for comments about these ideas. I am more than happy to volunteer my time in making it happen or even providing a proof of concept, if the node.js community agrees with me that this is something that could be useful.