Since the rule file was implemented first, the option names are still unchanged to date, but when introducing the -r command line option, I decided to go for short names instead.
This however is a bit confusing if you're used to -r and suddenly have to use different option names for the rule files.
Some options however are a bit difficult to unify, because they have different semantics:
The portEnd rule file option doesn't exist as an extra option in the CLI specification, but needs to be specified in a range notation, like eg. port=200-300.
Likewise, the fdName option is simply systemd=some_fd_name, but it might be a good idea to nest the option, resulting in systemd.enable and systemd.fdName.
The reject option also has three states in the CLI specification: disabled, enabled and enabled with errno.
I'm not quite sure what would be the best way to handle this yet, because if we'd use nested attributes, the port option would still be different because it's not simply a boolean with an optional string/integer value. When translating the port CLI option into a nested object, it would look like this for two different rules:
This clearly makes the port option much more confusing than simply having a port option along with an optional portEnd option.
Another way to approach this is to allow different types for those options, for example the systemd option would then either accept a boolean or a string. I'd consider this the ugliest option and it also won't work so well with the port option, except if we'd parse it in the same way as in the CLI specification and accept either an integer or a string.
Yet another way would be to keep the port/portEnd and reject/rejectErrno as is but just change the fdName option to something like systemdFdName.
Since the rule file was implemented first, the option names are still unchanged to date, but when introducing the
-rcommand line option, I decided to go for short names instead.This however is a bit confusing if you're used to
-rand suddenly have to use different option names for the rule files.Some options however are a bit difficult to unify, because they have different semantics:
portEndrule file option doesn't exist as an extra option in the CLI specification, but needs to be specified in a range notation, like eg.port=200-300.fdNameoption is simplysystemd=some_fd_name, but it might be a good idea to nest the option, resulting insystemd.enableandsystemd.fdName.rejectoption also has three states in the CLI specification:disabled,enabledandenabled with errno.I'm not quite sure what would be the best way to handle this yet, because if we'd use nested attributes, the
portoption would still be different because it's not simply a boolean with an optional string/integer value. When translating theportCLI option into a nested object, it would look like this for two different rules:This clearly makes the port option much more confusing than simply having a
portoption along with an optionalportEndoption.Another way to approach this is to allow different types for those options, for example the
systemdoption would then either accept a boolean or a string. I'd consider this the ugliest option and it also won't work so well with the port option, except if we'd parse it in the same way as in the CLI specification and accept either an integer or a string.Yet another way would be to keep the
port/portEndandreject/rejectErrnoas is but just change thefdNameoption to something likesystemdFdName.Given the following CLI invocation:
... here are how the ideas above would look like in rule file format:
Cc: @Profpatsch Cc: @kyren for providing helpful input for designing the CLI specification format back then