http.bro

Development
1

What's the reason for not providing a __load__.bro convenience for the optional packages?

For the optional packages, there'll be some which make sense to load
only in specific situations. My thinking is that by not providing a
__load__, we make sure people actually take a look at what they are
loading.

I'm not too strong on this though and do see the convinience of having
the __load__ there as well.

Another thing came to my mind: will "all.bro" be excluding optional
scripts/packages?

That depends on what all.bro's purpose is. So far we have primarily
used it for testing to make sure all scripts load correctly. For that,
the optional pieces should be included.

But perhaps we should provide two separate scripts: (1) the current
all.bro for testing, perhaps renamed to "test-all.bro" or something
like that; (2) an "all.bro" for users that pulls in all of the basic
stuff that's reasonable to load by default, but not including the
optional scripts. Perhaps we find a nicer name for that one too (it
would be kind of a new "mt.bro").

Robin

2

But perhaps we should provide two separate scripts: (1) the current
all.bro for testing, perhaps renamed to "test-all.bro" or something
like that; (2) an "all.bro" for users that pulls in all of the basic
stuff that's reasonable to load by default, but not including the
optional scripts. Perhaps we find a nicer name for that one too (it
would be kind of a new "mt.bro").

how about
  * default.bro
  * basic.bro
  * standard.bro

(just need to make sure that people don't get the impression that if
they just load that without looking any further anything will be fine....)

cu
Gregor

3

That sounds confusing. What would be the difference between default
and standard?

Robin

4

none. I though that either of those might be a nice new name for the
all.bro that user's would load. I.e., I would just pick one of those (or
maybe another name alltogether)

cu
gregor