[Bro-Dev] Feedback on configuration framework implementation
Johanna Amann
johanna at corelight.com
Thu Nov 30 10:28:19 PST 2017
On 30 Nov 2017, at 10:22, Jan Grashöfer wrote:
> On 30/11/17 19:01, Johanna Amann wrote:
>>> 1. Thinking of handlers that may change values and are associated
>>> with a
>>> priority, hooks come to my mind (e.g. Intel::extend_match). Are
>>> functions preferable compared to hooks here?
>>
>> In this case - yes. The problem with hooks is that they cannot return
>> a
>> value, which is used here to let user change (or reject) changes to
>> options. :)
>
> The Intel::extend_match hook allows changing values or rejecting as
> well. If the "chain of hooks" is "broken", i.e. one hook executed a
> break statement, the call to the hook returns false and (in that case)
> the log write is rejected. Otherwise, all changes made to the hook
> arguments inside the handlers are propagated allowing changes.
Ah, you have a point there it is possible to do it like that, I did not
think of that. I honestly also never liked modifying the values that are
passed in arguments; this is for example also theoretically possible for
events, but something that we have avoided to use in practice so far.
Functionally they are, however, obviously equivalent.
I think I prefer functions in this case from a stylistic point of view.
I am happy to change it over to hooks though if there is a consensus
that that is the more fitting approach here. :)
Johanna
More information about the bro-dev
mailing list