Risto, et al,
Advantages of input field within rule sets:
1. reduce or eliminate command line option inputs
Allowing input sources to be specified within rule sets
2. introduce events at specific points into rule sets
Without needing to setup sometimes complicated dependencies
Various contexts, jumps and goto's.
Perhaps this would simplify some rule sets
And be more directly defined instead of indirect contexts
3. allows for a "service" defined "endpoint"
Provides yet another mechanism to introduce and control
the flow of events (where a rule's context would determine
whether or not to even read from the input --
i.e. programmatic input control)
4. eliminates extraneous perl code to extract "input" file/source name
5. one could change the rule to point to another input
And then reload rule sets per SEC signals
could open new input after closing old input.
This could be useful for several reasons including
changing input streams, input-rule "versioning", introducing
new inputs and new rules without losing rule states, etc.
Since I have no immediate needs (since SEC currently supports current
input needs very well), I have not really thought through this and there
may be other advantages not noted. It's simply been on my mind to
discuss with you and others.
Regards,
Rock
-----Original Message-----
From: Risto Vaarandi [mailto:risto.vaara...@seb.ee]
Sent: Thursday, April 07, 2011 4:27 AM
To: simple-evcorr-users@lists.sourceforge.net
Subject: Re: [Simple-evcorr-users] Input field within rule definition
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
------------------------------------------------------------------------------
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
