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.

Reply via email to