On 7 Dec 2017, at 14:56, Azoff, Justin S wrote:
>> On Dec 7, 2017, at 5:22 PM, Johanna Amann
>> wrote:
>
>> Indeed, that is my thought. This seems like a job for broker, instead
>> of trying to somehow force this into a complex ascii-representation.
>>
>> Note that
> On Dec 7, 2017, at 5:22 PM, Johanna Amann wrote:
> Indeed, that is my thought. This seems like a job for broker, instead of
> trying to somehow force this into a complex ascii-representation.
>
> Note that this is just a limitation of the config reader - the rest of
On 01/12/17 23:59, Johanna Amann wrote:
> Which, after thinking about it for a few moments seems like the right
> choice in any case.:)
I think in case of hooks it might be a nice feature making hooks even
more useful. For events I agree that allowing to reassign atomic values
is undesirable.
> > 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.
>
> Yeah, and it also won't work for atomic values, at least not
On Fri, Dec 01, 2017 at 15:22 +, you wrote:
> Now I'm glad I never got it to work right :-)
Me too. :-)
Robin
--
Robin Sommer * ICSI/LBNL * ro...@icir.org * www.icir.org/robin
___
bro-dev mailing list
bro-dev@bro.org
> On Dec 1, 2017, at 9:58 AM, Robin Sommer wrote:
>
>
>
> On Thu, Nov 30, 2017 at 10:28 -0800, you wrote:
>
>> 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
On Thu, Nov 30, 2017 at 10:28 -0800, you wrote:
> 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.
Yeah, and it also
On 30/11/17 19:28, Johanna Amann wrote:
> 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. :)
I like the hook approach that is used in the Intel-Framework
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
> 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
On 29/11/17 23:02, Johanna Amann wrote:
> Hello everyone,
>
> the branch topic/johanna/config contains an implementation of the
> configuration framework as it was discussed in an earlier thread on this
> list. GitHub link: https://github.com/bro/bro/compare/topic/johanna/config
Nice! I am
Hello everyone,
the branch topic/johanna/config contains an implementation of the
configuration framework as it was discussed in an earlier thread on this
list. GitHub link: https://github.com/bro/bro/compare/topic/johanna/config
The implementation is basically what we discussed in the earlier
12 matches
Mail list logo