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" <da...@lang.hm>:

On Thu, 1 Dec 2016, mosto...@gmail.com 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.

Reply via email to