Sudheer - this was originally put in (TS-3650) precisely so we could add /
change configuration values on point releases, so that in particular LTS
releases could be tweaked to accept next major version configurations without
breaking current major release configurations. This is quite handy if you're
trying out the next major version vs. running on the LTS. The only real change
I'm proposing here is making this already existing facility usable from plugins.
James;
"If `proxy.config.james` is set then the value causes blah blah blah behavior.
If not set the deprecated configuration `proxy.config.peach` is used. If that
is not set either, the default value "Sudheer" is used.".
On Monday, November 21, 2016 4:25 PM, Sudheer Vinukonda
<sudheervinuko...@yahoo.com.INVALID> wrote:
I see - so, IIUC, the problem you are trying to solve really is the
*replacement* of an existing config setting with an altogether new config
setting?
In that case, I suppose, the proposed additional info may be used *if* we are
required to ensure backward compatibility, although, I'm not sure if that is a
mandatory requirement across major release updates (unless, of course, we
encounter a need to make this sort of change across a minor release update?).
> On Nov 21, 2016, at 2:18 PM, Alan Carroll <solidwallofc...@yahoo-inc.com>
> wrote:
>
> 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
> <sudheervinuko...@yahoo.com.INVALID> 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 <solidwallofc...@yahoo-inc.com.INVALID>
>
> To: "dev@trafficserver.apache.org" <dev@trafficserver.apache.org>
> 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
><sudheervinuko...@yahoo.com.INVALID> wrote:
>
>
> Hmm..what do you mean by "the administrator explicitly set B or C to the
> default value"?
>
>
>
>
>
>
