On Thu, 17 Jun 2010, RB wrote: > 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.
I don't see a big need to be able to have multiple parsers for a single input message the reason for having multiple parsers is to get the message from whatever garbage is going over the wire to a standard format that can then get processed by everything else. output formatting is where you would take that standard representation and customize it for whatever output channel you are using. I see a _lot_ of value in keeping the middle standard and making it so that input doesn't care what output will be used (and the output doesn't care what input was used), and neither one should care what sort of queue was used. > 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. it's possible to have the output of one ruleset go to other rulesets. I think this can cover this case. David Lang > 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 _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com
