<p dir="ltr">Hi,</p>
<p dir="ltr">On Jun 6, 2016 11:17 AM, "Fekete, Róbert" <<a href="mailto:robert.fekete@balabit.com">robert.fekete@balabit.com</a>> wrote:<br>
><br>
> Hi Bazsi, <br>
><br>
> I've started to document the grouping-by parser, and have a few questions/comments about it:<br>
><br>
> * It seems that some of the grouping-by options are the same (or very similar) to the correlation-related attributes of the pattern database, but have different names. Could we name them consistently where they are the same? (I haven't checked the correlation module from Rust, but maybe we could align that as well.) <br>
> For example:<br>
> grouping-by | patterndb<br>
> scope | context-scope<br>
> timeout | context-timeout<br>
> aggregate | message or action<br>
></p>
<p dir="ltr">I omitted the "context" prefix on purpose, they are important in the patterndb context as rules have correllation and non correllation related groups of options. With groupingby it would be kind of redundant.</p>
<p dir="ltr">I was thinking on aggregate() a lot, and decided to use something that is closer to the "groupingby" term, group by in SQL works with aggregate functions, in a sense they produce aggregates over various dimensions. In patterndb, you can generate multiple actions for a rule.</p>
<p dir="ltr">Anyway, naming should probably be discussed in person.</p>
<p dir="ltr">><br>
> * In the original commit message, you mention three possible values for the 'scope' option, whereas the context-scope in the patterndb has four (program). Are these deliberately different, or they use the same code?</p>
<p dir="ltr">They use the same code, so it should be the same<br><br></p>
<p dir="ltr">><br>
> * grouping-by doesn't look to me as an actual parser. From the existing objects, it resembles a filter more (IMHO), but I'd rather categorize it as something else that transforms/processes the incoming data, and should be therefore in a separate configuration object (along with the geoip parser). </p>
<p dir="ltr">I agree, we currently only have parsers/rewrite/filter stuff only. It might make sense to create a more generalized concept though. I am not sure it is worth it, but we already had similar usecases where we couldnt categorize some kind of functionality. But let's test whether we can find a descriptive name for it. How would you call "generic processing" in the config?</p>
<p dir="ltr">Btw, I stand by my decision that it is not a filter, it never drops messages, whereas the primary function of filters is to drop messages.</p>
<p dir="ltr">><br>
> Robert</p>