I was explaining the different variable/property types and the history around
the inconsistancy yesterday. Today I thought of a couple possible config options
that can't be made default without breaking things, but could be default on new
configs and simplify the variable mess.
1st, addressing the fact that properties can't be changed and so if you need to
customize anything you then have to first copy things to $! variables and then
use a custom template
global parameter property_override (default no/false)
if yes/true then any lookup of a property name ($foo or $$foo) first checks if
there is a $!foo variable, and if so uses that value instead
2nd, (related) addressing the historically based inconsistancy of some
'variables' being '$foo', some being '$$foo', and some being '$!foo'
global parameter property_fallback (default no/false)
if yes/true, than if a $!foo variable does not exist, return the value of
$$foo or $foo instead.
With both of these turned on:
all properties could be addressed as $!foo
changed by the config logic
the existing templates (including built-in templates) would work with the new values
eliminate the inconsistancy with $foo, $$foo, $!foo ($.foo and $\foo would still exist and be different)
** possible special handling needed for '$!' or '$!all-json'
CON:
slight performance hit in addressing properties as $! options need to be
checked.
possible confusion where debugformat doesn't show $!foo but using $!foo in the
code returns a value.
I think the probability of making these be on by default breaking existing
configs is fairly low, but non-zero. So I would have them be off by default, but
suggest to the distros that their default config include a global() section that
turns them on.
note: instead of 'yes/no' 'true/false', I considered '' '$!' and '$.' to allow
the use of $!foo or $.foo but after thinking about it a bit, I don't think the
added flexibility would be worth the complexity and confusion it could cause.
thoughts?
David Lang
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.
the inconsistancy yesterday. Today I thought of a couple possible config options
that can't be made default without breaking things, but could be default on new
configs and simplify the variable mess.
1st, addressing the fact that properties can't be changed and so if you need to
customize anything you then have to first copy things to $! variables and then
use a custom template
global parameter property_override (default no/false)
if yes/true then any lookup of a property name ($foo or $$foo) first checks if
there is a $!foo variable, and if so uses that value instead
2nd, (related) addressing the historically based inconsistancy of some
'variables' being '$foo', some being '$$foo', and some being '$!foo'
global parameter property_fallback (default no/false)
if yes/true, than if a $!foo variable does not exist, return the value of
$$foo or $foo instead.
With both of these turned on:
all properties could be addressed as $!foo
changed by the config logic
the existing templates (including built-in templates) would work with the new values
eliminate the inconsistancy with $foo, $$foo, $!foo ($.foo and $\foo would still exist and be different)
** possible special handling needed for '$!' or '$!all-json'
CON:
slight performance hit in addressing properties as $! options need to be
checked.
possible confusion where debugformat doesn't show $!foo but using $!foo in the
code returns a value.
I think the probability of making these be on by default breaking existing
configs is fairly low, but non-zero. So I would have them be off by default, but
suggest to the distros that their default config include a global() section that
turns them on.
note: instead of 'yes/no' 'true/false', I considered '' '$!' and '$.' to allow
the use of $!foo or $.foo but after thinking about it a bit, I don't think the
added flexibility would be worth the complexity and confusion it could cause.
thoughts?
David Lang
_______________________________________________
rsyslog mailing list
https://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com/professional-services/
What's up with rsyslog? Follow https://twitter.com/rgerhards
NOTE WELL: This is a PUBLIC mailing list, posts are ARCHIVED by a myriad of sites beyond our control. PLEASE UNSUBSCRIBE and DO NOT POST if you DON'T LIKE THAT.