Hmm..what do you mean by "the administrator explicitly set B or C to the default value"?
I'm not sure how the administrator can "play" around with default values? Or Did you mean, if a new version (release?) of trafficserver changed the default value for a setting? If it is the latter (changing default across releases), shouldn't our normal guidelines/warnings about compatibility across releases (generally, backward compatible across minor version updates, possibly not backward compatible across major updates) handle the consequences? > 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. > > > > 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. >>>>> >>>> >>>> >>> >>> >> >> > >
