[Bro-Dev] script loading changes

[Jonathan Siwek]

> > 1) When an @load or command line argument relies on BROPATH to
> >    search for the script/package, directory separator characters
> >    (i.e. '/') must be replaced with dots ('.').
> 
> Do we want to say "may" instead of "must"? So both versions would be
> acceptable.

So I take this to mean the search order for "@load a.b.c" would be
to look in BROPATH for "a.b.c", "a.b.c.bro", "a/b/c", then "a/b/c.bro".

And the search order for "@load a/b/c" would be "a/b/c" then "a/b/c.bro"

We could do that, but I think in the shipped scripts should use one
form consistently -- probably the dotted form or else we'd just be
adding a feature that never gets used.

And actually I think the search orders listed above should be reversed
to make the common case faster.

> > 3) A new "@add x when y ..." directive
> 
> One thing we haven't considered yet: what if "x" itself has new @loads
> or @adds? Can we make that well-defined?

If 'x' contains @loads, they get loaded immediately during the scan of 'x'
and set some flag to indicate we should go back to iterating from the
beginning of the current pool of @adds-to-evaluate to re-check dependencies.

If 'x' contains @adds, then those are added to the end of the pool of
@adds-to-evaluate (we should be somewhere in the middle of iterating over
the pool at this point).

Another problem I was thinking of was what happens when there's

  @add x when y
  @add y when z

And there's only an "@load z", creating a dependency chain.  To resolve
those cases, we can take the same approach I describe above and reset
the iterator to the beginning of the @adds-to-evaluate pool in order to
re-check dependencies whenever one of the elements evaluates successfully.

Dependency cycles will just get dropped on the floor if no element on the
cycle is ever explicitly @load'd.

- Jon