Sorry, A, B, and C are config variables, such as
"proxy.config.quick_filter.mask", "proxy.config.quick_filter.mask_in",
"proxy.config.quick_filter.mask_out".
On Monday, November 21, 2016 4:15 PM, Sudheer Vinukonda
<[email protected]> wrote:
Huh, I'm totally confused..Are "A", "B", "C" different config *settings* or
different *values* for a *given* setting? Your original reply seemed to
indicate (at least, the initial part of the reply) that they were *values* for
a given setting, but, the latest seems to indicate the opposite :-/
"The use case is providing backwards compatibility. Suppose a plugin uses
config value A. A newer version, in order to support additional features, uses
values B and C. It would be nice to be able to detect that neither B nor C were
explicitly set by the administrator in records.config and therefore the plugin
should fall back and use A. It is also required to *not* fall back to A if the
administrator explicitly set B or C to the default value. Therefore checking
the retrieved value against the default value is insufficient. One might use a
bogus default value then, but now there's a problem if none of A,B, or C was
set."
PS: I am only trying to understand the use case or need/benefits of having this
additional new info being proposed - not opposing the need for it!
From: Alan Carroll <[email protected]>
To: "[email protected]" <[email protected]>
Sent: Monday, November 21, 2016 1:55 PM
Subject: Re: Config variable source values
Let's say the default for B is "Sudheer". There are two cases I want to treat
differently.
1) No mention of B is in records.config. Fall back to A.2) In records.config,
the value for B is set to "Sudheer" by the administrator. Use this value, do
not look at A.
On Monday, November 21, 2016 3:32 PM, Sudheer Vinukonda
<[email protected]> wrote:
Hmm..what do you mean by "the administrator explicitly set B or C to the
default value"?
