> On Nov 21, 2016, at 1:22 PM, Alan Carroll > <solidwallofc...@yahoo-inc.com.INVALID> wrote: > > 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.
I don’t think this is sane :) There’s no effective difference between a default value and a configured value. Mentioning a configuration value in `records.config` doesn’t mean “really make this so”, it just sets that value. So the newer plugin should just use B and C. Fallback to A would make sense if B and C are not present (eg. the value is a NULL string or some designared int), but this is specific to the plugin and unrelated to where the configuration value was set. Ad default is just as legitimate as an explicit configuration. "It is also required to *not* fall back to A if the administrator explicitly set B or C to the default value” This requirement leads to extremely confusing behavior and IMHO it is best to not go there. > On Monday, November 21, 2016 3:02 PM, Sudheer Vinukonda > <sudheervinuko...@yahoo.com.INVALID> 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 >> <solidwallofc...@yahoo-inc.com.INVALID> 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 <jpe...@apache.org> >> wrote: >> >> >> >>> On Nov 21, 2016, at 11:50 AM, Alan Carroll >>> <solidwallofc...@yahoo-inc.com.INVALID> 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 <jpe...@apache.org> >>> wrote: >>> >>> >>> >>>> On Nov 21, 2016, at 9:14 AM, Alan Carroll >>>> <solidwallofc...@yahoo-inc.com.INVALID> 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 <jpe...@apache.org> >>>> wrote: >>>> >>>> >>>> >>>>> On Nov 21, 2016, at 7:20 AM, Alan Carroll >>>>> <solidwallofc...@yahoo-inc.com.INVALID> 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. >>>>> >>>> >>>> >>> >>> >> >> > >
