Adding More Transport Protocols - A Proposal

What follows is a thought dump, so sorry if it rambles a bit.

This module is in a pretty good state with the HTTP Protocol, so i started thinking about what the next protocol that could be added.

As I thought about it, I realized a couple things.

This first is we probably need to make our top level Receiver and Emitter a little more generic. At the moment, they have things related to the HTTP Protocol in them.

This second thins is when we add a new transport protocol in, we are also potentially going to increase the dependencies for each one added. My assumption would be that we would use a library related to that transport protocol for emitting events. For example, if we added MQTT then we might use the mqtt module.

The problem, and maybe it isn’t a problem, is that a user might only want or need 1 protocol, and if we had multiple protocols implemented, then they would be getting more dependencies than needed.

One solution to this could be creating new modules that depend on this module as a base for each of the new Protocols. I would assume we would just keep the HTTP protocol in the base module since, and i have no data to back this up, it might the most common to use. So if a user wanted the MQTT protocol, they could just install that module. However; if they wanted to use multiple protocols, I could see this becoming a little messy.

Another solution i thought about was some sort of plugin architecture, but i not really sure of the UX of it. with this case we would still be creating separate modules to plugin, but there would be one “entry point” to creating new Emitters and Receivers

Again, this was a thought dump to start a discussion on our best path forward.

[lance]

@lholmquist I think we can probably push 3.2.0 with deprecations for everything under src/transport, and the addition of src/messages, since it’s only additive. This way, we can document and promote the usage of Message instead of the hackey transport bits, and even iterate on the new stuff, fixing any bugs that are found and potentially changing the API until 4.0.0 when we remove src/transport and src/messages becomes a fixed API with breaking changes requiring major version bumps. What do you think?

I’m thinking it’s probably time to create a WIP pull request for detailed feedback if folks have it.

[lholmquist]

Regarding Deprecations. I wonder if we should have some sort of deprecation policy for the future. Is it to overkill to deprecate a feature and then need to wait for 2 major releases before it is removed?

So for example, we release a 3.2 which has deprecation notices for Receiver and Emitter, then in 4.0 we introduce the new way from the above post, but we don’t remove the old way until 5.0?

Thats similar to how node core does things, but maybe we don’t need to be that process heavy and a new major version is fine for removal. But we should probably do a minor release of the current version adding the deprecations in