`message_bus` doesn't deliver unknown messages

[edobez]

Somewhat I expected that the message_bus would deliver all the messages no matter what, even if the destination routers wouldn't accept the messages. That was my expectation because when posting messages directly to routers, they would end up in the on_receive_unknown when they are not accepted. If this is the correct behavior, then it should be clarified in the documentation and maybe offer a way to still deliver the messages and let the routers handle it.

[jwellbelove]

The etl::message_bus does not deliver messages to a router that the router does no accept to stop a potentially large number of routers all trying to process messages that they don't understand, every one of them calling on_receive_unknown. I saw this as an unnecessary overhead. I don't see the advantage in causing multiple routers to trigger an unknown message call.

on_receive_unknown was intended to be more of a debugging aid to allow the coder to detect that a router had been sent a message that it didn't (yet?) accept.

At the moment etl::message_bus::accepts(const etl::imessage& msg) always returns true. Normal message routers will, if they do not accept a message type, interrogate any successor router. It may be better if etl::message_bus were to interrogate all of the subscribed routers. Thereby a return of false from a message bus would indicate that no router in the stack will process the message.

[edobez]

Thanks for the clarification.

The etl::message_bus does not deliver messages to a router that the router does no accept to stop a potentially large number of routers all trying to process messages that they don't understand, every one of them calling on_receive_unknown. I saw this as an unnecessary overhead. I don't see the advantage in causing multiple routers to trigger an unknown message call.

I also believe this is the right approach, but for me was not entirely clear from the class description. Actually I thought that I needed a broker to achieve that kind of filtering.

At the moment etl::message_bus::accepts(const etl::imessage& msg) always returns true. Normal message routers will, if they do not accept a message type, interrogate any successor router. It may be better if etl::message_bus were to interrogate all of the subscribed routers. Thereby a return of false from a message bus would indicate that no router in the stack will process the message.

On one hand I see why a message bus would always return true: the user of a bus should not care/know about who subscribes to it, in the optics of decoupling. However in practice it might be useful to interrogate a bus to know if there is any subscriber able to receive a given message.

[jwellbelove]

I'll put it out to the Slack group to see what the general opinion is.