> > I don't really have a problem with forward references, but I think my > > objection is more to the fact that its an input that is declaring its > > ruleset, whereas I think it would be more logical to bind inputs to > > rulesets. ie, declare your inputs, your templates, your filters, and > > your actions, and tie them all together using rulesets. > > mhhh... Good that you bring up this point. To me it looks much more > natural > that the input specifies its "sink". I actually hadn't thought the > other way > round. Now after reading your post, I realize that it is actually > either way. > > Let me think a little bit about this (BTW: I am out of office tomorrow, > so > silence on my part doesn't mean diminishing interest ;)). I'll driving > out > shortly, but I hope to be able to look and reply to mail later this > evening. > In any case, now I have something to think about during the drive ;)
After my long drive, I now know why I find it natural to specify the ruleset to bind to inside the input. In my point of view, there is a n:1 relationship between inputs and rulesets. After a message is received, the input must place the message somewhere. This somewhere is a ruleset. Hypothetically, one can think about an n:m relationship, so that an input can have more than one ruleset that the message is being submitted to. However, I am a bit skeptic if that is really useful: because what happens is that the input must then duplicate the message and submit it to multiple rulesets/queues. That is another interface where messages may be multiplexed to various next destinations. It also means that we need some more object/code that handles the n:m relationship, where the input hands over the message to that object and that then multiplexes it to the receiving rulesets. While this is not necessarily a big performance hit, I have learned that small hits also accumulate. Also, it increases code complexity. So rather than doing it this way, I prefer to think about the input submitting a message to a single ruleset. Then, the ruleset can decide what to do with the message. Most importantly, it may decide to push all messages to other (sub-) rulesets. With the current system, this goes only via omruleset, which is kind of a quick hack. With the new system, I could simply do an include/copy automatically during creation of the config tree. Is there any good argument that backs a n:m relationship? Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
