On 04/05/2011 11:54 PM, MILLS, ROCKY (ATTSI) wrote: > For discussion only -- not an immediate need to be addressed. > > ~ >
Well, the 'input' field looks like a synonym to the file context to me... Maybe I haven't got all the details for the 'input' field, though. However, there is one danger related to the use of 'input' that file contexts don't involve -- if the locations/names of input files change, you have to modify many rules of the rule base. In contrast, with file contexts there is no such issue, since the context name does not reflect the physical location of the input in the file system. But again, maybe I haven't picked up every detail of your proposal properly... What other benefits would 'input' have over file contexts? I have to admit that I'd personally rely on Jump rules and 'goto' continue statements. kind regards, risto > For some rule sets I've defined "context" per multiple files per the SEC > command line options. E.g. -input=/app/myapp/log/my.log=mylog. In this > way I can specify rules per specific files by simply using the defined > context such as context=mylog. This works well but every rule preceding > the "mylog" rule will attempt to process input from all input sources > and I have some rather noisy logs to monitor. And I know the jump and > goto rules could also be used to address this. > > As an optimization (I'm guessing but wouldn't really know enough about > the SEC internals without looking), I'm thinking a rule could have an > input field such as input=/app/myapp/log/my.log or even non-file types > of inputs. > > The obvious advantage is that specific inputs would be separated into > their own streams and target an initial rule. And given that TakeNext > was assigned to the rule, I would expect the following rule to process > the input even if it doesn't have an "option=" defined. This would > allow inputs to effectively be injected midstream into a ruleset > depending on where the "input" was placed. > > Given that two rules have input defined, I would expect the sequence (as > currently defined) to be followed with the first rule and only passed > along to the next such rule if "TakeNext" was defined. Though I haven't > thought this through. > > And of course there are multiple rule files and potential issues and > decisions that would need to be considered. > > Anyway, just brainstorming and perhaps other folks may recognize some > other benefits from such an approach. > > Regards, > Rock > > ------------------------------------------------------------------------------ > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > _______________________________________________ > Simple-evcorr-users mailing list > Simple-evcorr-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users > ------------------------------------------------------------------------------ Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
