[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. :)


More information about the bro-dev mailing list