Ok, my mistake was thinking each else needed it's own {}, which results in a lot
of closing } at the end of the sequence.
David Lang
On Thu, 1 Dec 2016, Rainer Gerhards wrote:
Just on elseif... We have it, it's just a question of writing style. Insert
a space and you get:
If expr
Else if expr
Else if expr
Else
So there is no need for a special statement. Note that for the very same
reason, elseif does not exist in many programming languages. C, for
example, does not have it.
Rainer
Sent from phone, thus brief.
Am 01.12.2016 23:05 schrieb "David Lang" <[email protected]>:
On Thu, 1 Dec 2016, [email protected] wrote:
Hi
Is there any way to dynamically invoke a ruleset? eg: call $var
(I'm trying to avoid having +200 if statements...
sigh, this is getting a wee bit frustrating, you keep saying "it hurts
when I do X", we say "that doesn't work well, do Y" and you come back a day
or so later saying "but it really huts when I do X"... (it doesn't help
when we ask you to provide information and you instead spend hours trying
other things)
some tools require you to split the logs up early and have completely
seprate processing of each log type in order to scale (mostly because their
speed in any one thread is so horrible), rsyslog is architected for very
high performance when you keep everything together and only split it up in
limited cases.
now that I have expressed my frustration, you are finding bugs, helping to
fix them, and raising some good questions along the way. Just understand
why once in a while our answers seem a bit curt.
while I can see the use cases for "call $.var", what would you do if you
call a ruleset that doesn't exist? you would first have to do 'if $.var ==
[array of legal values] then' to be safe.
You don't like having lots of
if <condition> then {
stuff
stop
}
there are several approaches to doing this
1. just a bunch of if statements
performance cost of doing a bunch of if tests
easy to include additional tests from a directory of files
2. if then else
same number of tests
no need for stop
lots of trailing brackets
not include friendly
if <condition> then {
} else {
if <condition> then {
}
}
3. add elsif
same number of tests
no need for stop
no odd trailing brackets
more include friendly thatn #2, but not as much as #1
if <condition> then {
}
elseif <condition> then {
}
4. switch statement
no faster than the above, but with potential for config optimization
cannot do more complex conditions
similar include impact as #3
switch $.var {
case "value" {}
case "value" {}
}
5. variable call statements
what to do if called ruleset doesn't exist?
include friendly if you don't have to have a guard test first
call $.var
6. function lookup tables
solves the 'unknown thing to call' proclem
requires compiling config snippets at table load time
cannot do complex tests
table lookup could be extended to expand the sparse-array concept to
string (solving the common 'startswith' type of test)
exec table_lookup(functions,"$.var")
now, looking at them in terms of complexity to implement
#1 and #2 exist today
#3 (elsif) seems like a fairly simple change to support
#4 (switch) is a bit more complex
#5 (call var) sounds like it's easy to implement
#6 (function pointers) is significantly more work
Personal opinion
I'd like to see us add elsif (#3), it significantly cleans up long
if-then-else cascades.
I think that with elsif, the need for switch (#4) is low, and the
restrictions of it only doing simple equivalence tests (no startswith,
contains, etc) really limit it's use
call var (#5) seems easy to implement, but I really don't like opening up
the problem of calling a non-existant ruleset. We could have it silently do
nothing, but that gets really messy and I am already cringing at the
troubleshooting exhanges we will have to help people figure out what
is/isn't happeing.
function pointers are by far the most complicated, and since they include
ruleset parsing after startup, they have the potential to be really ugly to
implement. On the other hand, they are also by far the most powerful. If we
could do things like limiting the functions so that they can't do any of
the startup-type things[1] and only include statements that are normally
executed for each log type, this would also give us a back-door way of
providing the dynamic configuration that many people have been asking for.
Internally, this could be implemented by creating rulesets and calling
them based on the result of the lookup.
[1] no changes to global() or main()
no loading modules.
probably no creating inputs
possibly allow template creation
just set and action() calls
David Lang
_______________________________________________
rsyslog mailing list
http://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.
_______________________________________________
rsyslog mailing list
http://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.
_______________________________________________
rsyslog mailing list
http://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.
