What do people think about splitting up portions of init-bare into separate files, and having init-bare simply @load those files? Right now, it’s a 4500+ line script that keeps growing, and it commonly results in conflicts.
For the protocols, I could see having a file such as protocols/kerberos/bare.bro which defines the appropriate types which are currently in init-bare.
–Vlad
That sounds like a good idea - I am not a big fan of the fact that a lot
of the protocol dependent datatypes are in init-bare currently.
I am just not sure if it might require a lot of fiddling to get the load
order of things correct; but assuming that every protocol has a bare.bro
(or perhaps a datatypes.bro or similar?), that should not be a huge issue.
Johanna
Yeah, I can see that. It would be nice, though, if init-bare.bro
wouldn't need lots of @load statements then to refer to the individual
files. Maybe we could add some automatic way instead, like calling the
files __bare__.bro and have Bro find them automatically (but to
Johanna's point, not sure if that would cause load-order problems).
Robin
If we started structuring the analyzers internally more like external plugins with the scripts and everything in them, it would feel more comfortable to me. It seems like we'd be able to keep all of a protocol ephemera tied closely with it.
Would that work? I know that internal and external plugins have some differences, but I don't know if that means we're limited in a bit in how we handle script land required data structures for analyzers.
.Seth
For init-bare-style initialization code I was thinking the same, and
that's also partially where my __bare__.bro idea came from (actually
__init__.bro would be nicer I'm thinking now). I went back to the
plugin structure to see if we have the right mechanism there already,
but they work slightly different in terms of when required data
structures get initialized. But we could make those __init__.bro
scripts work in either case I think.
For a more general reorganization of moving scripts and code together,
I'm still torn on that. I like that in theory, but haven't convinced
myself yet that I'd like it in practice. 
Robin