I really like the new script layout. Having just poked at it, it really is a lot easier to find stuff in there
I do however have some quick comments:
* I would rename "all.bro" to "default.bro". I think "all" is
misleading, since it doesn't load everything, it rather loads the
default config.
* I would also rename use the extension ".init" for the file, since its
automatically loaded by the core without script intervention. I.e.,
call it "default.init".
* I would move the test check whether "default.init" should be loaded
into the core and not handle that at the script level.
* Does it make sense to do some BROPATH magic? For each path in
BROPATH, we could automatically add "/policy", "/site", "/base"?
But YMMV.
I'd like to see the first three points. Not so sure about the last one though.
* I would rename "all.bro" to "default.bro". I think "all" is
* I would also rename use the extension ".init" for the file, since its
* I would move the test check whether "default.init" should be loaded
into the core and not handle that at the script level.
I like these (the final one only if we did a command line option
though).
* Does it make sense to do some BROPATH magic? For each path in
BROPATH, we could automatically add "/policy", "/site", "/base"?
But YMMV.
* I would rename "all.bro" to "default.bro". I think "all" is
* I would also rename use the extension ".init" for the file, since its
* I would move the test check whether "default.init" should be loaded
Agreed on all points. I'll make sure those happen soon.
* Does it make sense to do some BROPATH magic? For each path in
BROPATH, we could automatically add "/policy", "/site", "/base"?
But YMMV.
I agree with Robin here. If we start adding lots of directories to the BROPATH it would get confusing to tell where something is loading from when you see "@load xxx" in a script.
* I would also rename use the extension ".init" for the file, since its
automatically loaded by the core without script intervention. I.e.,
call it "default.init".
I don't like the use of ".init" for anything. To me, that's implying it might not be the same language as the other scripts. Is there an advantage of using the exceptional extension? Maybe it was originally meant to imply it's an internal script, but now anything in "base/" could almost be considered "internal".
Just throwing out an idea: use a "default.bro" and then change "bro.init" => "core.bro".
That's actually a really good point. I think I could go for that. The first time I saw the bro.init script I was pretty confused since it's just a plain Bro script.
it might not be the same language as the other scripts. Is there an
advantage of using the exceptional extension?
It indicates that loading them is hard-coded into the core, there's
nothign the script-level can do about that. But you're right in that
the .init extension can be misleading.
Maybe it was originally meant to imply it's an internal script, but
now anything in "base/" could almost be considered "internal".
These scripts are still different than the other base/* stuff, which
is loaded from other scripts. I'd like to keep that distinction
somewhow. How about using a prefix, like "init-bare.bro" and
"init-default.bro" instead?
"bro.init" => "core.bro".
(Let's avoid the term "core", that's already overloaded.)
These scripts are still different than the other base/* stuff, which
is loaded from other scripts. I'd like to keep that distinction
somewhow. How about using a prefix, like "init-bare.bro" and
"init-default.bro" instead?
