zmstone
commented
12 months ago I believe that introducing an entirely new message processing system outside of the rule engine would increase the overall system's complexity and the learning curve for users. I suggest expanding the capabilities of the rule engine by adding a few configuration options to allow the rule engine to terminate message flow and alter the original message content.
In my personal experience, most users do not need to terminate or modify messages in transit. However, if a user has such a requirement, they typically want all rules to have the capability to modify message flow, rather than requiring a few specific rules to refrain from altering message flow. Therefore, we can introduce a global configuration option in the rule engine's settings, something like
rule_engine.message_flow_intrusive = boolean(), with a default value offalse, indicating that it does not affect message flow.With the concept of intrusive message flow, we must define the sequence of flow. We don't need to handle hooks because we've already hardcoded the order of hooks. However, the order of rules still needs to be determined. Therefore, we can add a global configuration in the rule engine:
rule_engine.message_flow_order = ["rule_name_001", "rule_name_002"].For each rule, we can add a configuration, for example:
rule.rule_name_001.message_flow_action_if_matched = "stop_message_flow" | "disconnect_connection" | "none". This will terminate message flow or disconnect the connection after executing all actions, where "none" indicates taking no action, and the message will continue to flow to the next rule and then to other plugins if "rule_name_001" is not matched.
From UI/UX point of view, this new feature can be positioned close to the rule engine rules. But maybe not a good idea to extend the current separation of rule + action design as I replied above https://github.com/emqx/eip/pull/81#discussion_r1414170353
I believe that introducing an entirely new message processing system outside of the rule engine would increase the overall system's complexity and the learning curve for users. I suggest expanding the capabilities of the rule engine by adding a few configuration options to allow the rule engine to terminate message flow and alter the original message content.
In my personal experience, most users do not need to terminate or modify messages in transit. However, if a user has such a requirement, they typically want all rules to have the capability to modify message flow, rather than requiring a few specific rules to refrain from altering message flow. Therefore, we can introduce a global configuration option in the rule engine's settings, something like
rule_engine.message_flow_intrusive = boolean(), with a default value offalse, indicating that it does not affect message flow.With the concept of intrusive message flow, we must define the sequence of flow. We don't need to handle hooks because we've already hardcoded the order of hooks. However, the order of rules still needs to be determined. Therefore, we can add a global configuration in the rule engine:
rule_engine.message_flow_order = ["rule_name_001", "rule_name_002"].For each rule, we can add a configuration, for example:
rule.rule_name_001.message_flow_action_if_matched = "stop_message_flow" | "disconnect_connection" | "none". This will terminate message flow or disconnect the connection after executing all actions, where "none" indicates taking no action, and the message will continue to flow to the next rule and then to other plugins if "rule_name_001" is not matched.