> On Dec 1, 2016, at 9:39 PM, Robin Sommer wrote:
>
> Bro's current Broker framework has a few pretty inelegant API parts
> because Bro's scripting language doesn't support some of its
> operations well currently. I've put some thoughts together on
> potential language extensions to improve the s
On Fri, Dec 02, 2016 at 14:19 +, you wrote:
> Something like this with when statements would be
> unmaintainable:
Yeah, exactly.
> local v1 = Broker::lookup(h, 41);
> local v2 = Broker::lookup(h, 42);
> local v3 = Broker::lookup(h, 43);
> Having a way to send a batch of operations would b
> On Dec 1, 2016, at 9:39 PM, Robin Sommer wrote:
>
>https://www.bro.org/development/projects/broker-lang-ext.html
>
> Feedback welcome, this is just a first draft.
Looks like a big improvement, some ideas:
Not that syntax is super important to nail down right away, but to me, “v as T”
s
> Feedback welcome, this is just a first draft.
I like this. Some initial feedback:
- In the switch statement, I would require that a user either provide
a default case or fully enumerates all cases. Otherwise it's too
easy to cause harder-to-debug run-time errors.
- For the abbrevia
I really like the suggested improvements and I agree to Jon and Matthias
regarding the use of "async" to make corresponding calls explicit. The
first thing I thought of was the get_current_packet() or the
get_current_packet_header() function. If there is some asynchronous
execution in context of a
