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.
On Monday, November 21, 2016 3:02 PM, Sudheer Vinukonda
<[email protected]> wrote:
I'm curious to know the use case, if any, in where one'd care if a "default"
value for a setting came from the source code or from records.config.
Consequently, I wonder if it is sufficient to know that a given setting has a
"default" value or a non-default value.
It might also be helpful if you can enumerate the possible combinations of
values and the corresponding source/explicit value that they mean.
- Sudheer
> On Nov 21, 2016, at 12:52 PM, Alan Carroll
> <[email protected]> wrote:
>
> No, they behave very differently. If you have a config variable in
> RecordsConfig.cc and it's not mentioned in records.config you get
> REC_SOURCE_DEFAULT. If you have a plugin created config variable that is not
> in records.config you get REC_SOURCE_EXPLICIT. In both cases if the value is
> in records.config you get REC_SOURCE_EXPLICIT. So for a built in it is
> detectable if the value is in records.config, but not detectable for a plugin
> created variable.
>
> On Monday, November 21, 2016 2:34 PM, James Peach <[email protected]>
>wrote:
>
>
>
>> On Nov 21, 2016, at 11:50 AM, Alan Carroll
>> <[email protected]> wrote:
>>
>> No, the source is REC_SOURCE_EXPLICIT even if the variable is not mentioned
>> in records.config. How else can a plugin tell if a config variable it
>> creates has a value in records.config?
>
> I think I’m confused about what you are proposing then. It sounds like
> configuration records used by plugins behave just like configuration records
> used by traffic_server. Is that the case? If so, it sounds like correct
> behavior to me. If not, what is the problem that you are addressing here?
>
>>
>>
>> On Monday, November 21, 2016 12:21 PM, James Peach <[email protected]>
>>wrote:
>>
>>
>>
>>> On Nov 21, 2016, at 9:14 AM, Alan Carroll
>>> <[email protected]> wrote:
>>>
>>> REC_SOURCE_EXPLICIT - see TSMgmtStringCreate in InkAPI.cc (around line
>>> 8896). That is the same value as setting the value in a configuration file.
>>
>> That sounds correct to me. The value was set in a configuration file and is
>> being consumed by a plugin.
>>
>>> On Monday, November 21, 2016 10:29 AM, James Peach <[email protected]>
>>>wrote:
>>>
>>>
>>>
>>>> On Nov 21, 2016, at 7:20 AM, Alan Carroll
>>>> <[email protected]> wrote:
>>>>
>>>> The config variable sourcing data was originally put in to be able to
>>>> detect that a variable was set even if that setting was the same as the
>>>> default (otherwise this is impossible to reliably determine). I am working
>>>> with a plugin that defines its own config records but as far as I can tell
>>>> (1) the source value for a plugin configured record default is the same as
>>>> for an explicitly set value and (2) the source information is not
>>>> available via the plugin API.
>>>
>>> What is the source when you specify a record in records.config, then
>>> register it from a plugin?
>>>
>>>> I would like to fix both of these.
>>>> First, add a "PLUGIN" value to RecSourceT to indicate the value is set as
>>>> a default by the plugin and use EXPLICIT only for values from
>>>> configuration files or explicit value setting API calls.
>>>> Second,
>>>> * Move or copy the RecSourceT define to apidef.h.in.* Add
>>>> TSMgmtSourceGet(const char*) to return the RecSourceT value for a
>>>> configuration variable.
>>>>
>>>
>>>
>>
>>
>
>
