<p dir="ltr">Hi,</p>
<p dir="ltr">On Jun 6, 2016 11:17 AM, &quot;Fekete, Róbert&quot; &lt;<a href="mailto:robert.fekete@balabit.com">robert.fekete@balabit.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi Bazsi, <br>
&gt;<br>
&gt; I&#39;ve started to document the grouping-by parser, and have a few questions/comments about it:<br>
&gt;<br>
&gt; * 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&#39;t checked the correlation module from Rust, but maybe we could align that as well.) <br>
&gt; For example:<br>
&gt; grouping-by  |  patterndb<br>
&gt;   scope          | context-scope<br>
&gt;   timeout       | context-timeout<br>
&gt;   aggregate   | message or action<br>
&gt;</p>
<p dir="ltr">I omitted the &quot;context&quot; 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 &quot;groupingby&quot; 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">&gt;<br>
&gt;   * In the original commit message, you mention three possible values for the &#39;scope&#39; 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">&gt;<br>
&gt;  * grouping-by doesn&#39;t look to me as an actual parser. From the existing objects, it resembles a filter more (IMHO), but I&#39;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&#39;s test whether we can find a descriptive name for it. How would you call &quot;generic processing&quot; 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">&gt;<br>
&gt; Robert</p>