Hey Eric, I think the intention of the “parameters” was to have a place to store the pieces that don’t fit into rules; I don’t think this has been very well planned out yet, and I also don’t think the examples listed make sense… I think a much better example is initial dispersion, which, while affecting the delivery services behavior, is applied in Traffic Router, where it wouldn’t make much sense to represent things in the rule format that might be used on the cache side. Another better example is the long_desc fields, they don’t have any configuration effect on the cache, but are used for various things.
-MM On 9/5/17, 7:01:29 AM, "Eric Friedrich (efriedri)" <[email protected]> wrote: Actual Wiki link is here: https://cwiki.apache.org/confluence/display/TC/Configuration+Management#ConfigurationManagement-Rules_Engine What is the difference between a parameter and a service rule? From the examples, it looks like parameters are all the legacy behaviors we have today and rules are many of the new behaviors we will shortly be adding. Today we have a delivery service configuration that has many parameters (configuration) that are associated with implicit service rules (behaviors). For example, setting the Geoblock field contains configuration (CZF-only, which countries to allow) and there is always a hardcoded "service rule” to make use of that configuration. The two “parameter” examples below follow the same pattern - For active/non-active the configuration is boolean and the service rule either processes requests on that DS or rejects them - For Query Strings, the configuration is “use”, “ignore”, “drop” and there is a service rule that implements the logic for those 3 options. Similarly all of the Service Rules example can be broken into configuration + behavior. It will be more work in the short term to get to this model, but IMO is more cohesive than having some behavior be parameters and some behaviors be service rules.
