[Bro-Dev] script loading changes

[Jonathan Siwek]

> More relevant, though: I'm kind of worried that @load x when y would
> break logical encapsulation a little bit (since it seems like 'load x
> when y' essentially means that something other than x needs to be
> aware of exactly what x needs to load in order to run).

"@add x when y" isn't actually saying that y is required for x to work
(I guess generally it will be), but rather that there's a condition
that must be met before loading 'x'.

But I think you're right that, for how we'd use it, it's weird for
'x' itself to not be maintaining the conditions that are required to
load it.  It's going to be hard to maintain "@add x when y" statements
because you have to look whether you need to change any whenever you
change what 'x' is loading.

Let's step back for a second, I'm not seeing why we're coming up with
such complex solutions anymore.

The problem we're trying to solve is how to best organize the packages
under protocol/ such that there's a way to load them without a possibly
unwanted side-effect of loading an entire package under frameworks/
because one script happens to require it (is that right Seth?).

e.g. we want "@load protocols/http" to avoid loading frameworks/software.

Why don't we just write the __load__.bro manifest of the package to not
@load scripts that may have unwanted side effects?  The __load__.bro that
gets loaded implicitly is already provided only for convenience and may
not actually load the entire contents of the package.

I think a user should have three choices:

1) pick & choose exactly what scripts you want from a package
2) rely on a package's __load__.bro to pick a minimal set of scripts
   from the package that best reflect its core functionality
   e.g. via "@load protocols/http"
3) the "I don't care how much extra stuff gets loaded, give me everything
   in the package" approach via "@load protocols/http/*" to recursively
   load all files that have a .bro extension (skipping __load__.bro)

Only #3 is new functionality.  These choices make it quite clear to the
user what to expect, while the @add/when conditional loading stuff is going
to appear a bit magical and hard to troubleshoot.

- Jon