On 12/13/2011 08:26 PM, Mark D. Nagel wrote: > On 12/13/2011 4:20 AM, Risto Vaarandi wrote: >> hi all, >> some months ago, we had a discussion on rewriting input events: >> >> http://sourceforge.net/mailarchive/forum.php?thread_name=4E066179.3010304%40willingminds.com&forum_name=simple-evcorr-users >> >> >> Would a similar feature be of interest to the end users? :) >> I was thinking about attacking the problem in a more general way, but >> couldn' find a truly elegant solution :( > > Obviously, I'd still like that :). We are in the middle of planning a > change of Windows Event Log export tools, and of course the format is > different. Instead of rewriting all our rules, we could instead > transform the new input to look like the old input. Of course, with > the new cached pattern tools, we could redo our rules once to extract > the fields we need and then change the extraction rules instead to match > the new input, using the cached fields in the revised ruleset. > Regardless, being able to transform input in place with no other changes > in context, etc. would be a handy tool to have available. > > Thanks, > Mark >
This discussion has also a wider context around it -- while looking into opportunities for modifying data in input buffer, I realized that things will get tricky if one attempts to modify several buffered input lines. This leads to another idea of setting up a separate input buffer for each input file. So far, patterns for multiple lines have been meaningful and reliable only for "one input file" scenarios. Having multiple inputs means that lines from these files can arrive in any order, thus patterns like RegExp2 or RegExp7 are not guaranteed to always provide the same result on the same set of input lines. However, if there would be a separate buffer for each input file (plus one for synthetic events), multiple line patterns would become lot more functional, because the pattern matching is always done strictly for one file's data. The downside of this approach is inability to match data from different files simultaneously with one pattern. Although this mechanism is inherently unreliable, there *might* be some sites which are actually using this (for example, deliberately accepting the 30% or 50% probability for undetected events??) Therefore, I'd like to ask from the user community if the separation of input data into multiple buffers would be acceptable. Please bear in mind that as a result, patterns like RegExpN (N > 1) could not be used for matching several lines from *multiple* input sources with *one* matching operation. What are the opinions? (I am not promising to implement this as a new feature, but before studying it in more detail, I'd like to know if it's worth to do so.) kind regards, risto ------------------------------------------------------------------------------ Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure _______________________________________________ Simple-evcorr-users mailing list Simple-evcorr-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/simple-evcorr-users
