On Thu, Jun 17, 2010 at 15:47, Rainer Gerhards <[email protected]> wrote: > I think you actually missed on level. At the top there are rulesets. These > are composed out of multiple rules. Each rule than is composed of a filter > (selector) and multiple actions. This hierarchy already exists in v5, but the > top level is seldom used. > > I am talking about the relationship between inputs and rulsets (not rules). > What I intended to say is that I don’t see a need that a single input can be > bound to more than one ruleset. On the other hand, it is definitely necessary > to have the ability to bind a ruleset to more than one input. > > I hope that clarifies.
It does clarify; I did indeed miss the rule->ruleset relationship. To justify an m:n relationship, then, I think you'd have to evaluate what features other than sub-rules a ruleset provides. So far as I can tell from reading the docs in the source tree, there are currently two: independent queues and message parsers. It is conceivable (but perhaps not practical) that a user may want to parse a given message multiple ways, or to queue differently based on the speed of a given rule+action. If rules themselves had independent queues and message parsers, then that would return to the 1:n. That is to say, as long as there are features unique to rulesets, it is conceivable that a user would desire to map a single input to several of them. Please do note, I've not had cause to dig through all of v5's features, so what I speak of may already be addressed. RB _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
