[Bro-Dev] Bro script organization

[Seth Hall]

This is my proposed organization standard for the Bro policy scripts since we are now breaking them down into directories by their functionality and use.  I'd like to get feedback on if I've missed any areas of functionality or something should be made clearer.  Once we reach some consensus I'll be documenting this on a web page and I'll go back through the existing new scripts and make sure I've followed all of the rules. :)

Here are the guidelines....

frameworks/
	- These wrap up reusable chunks of functionality. (i.e. notice, cluster, communication, logging, metrics, etc)
	- Can load other frameworks and utils.
	- Never load protocol specific scripts.  Something is probably designed wrong if you feel like you need to load a protocol analysis script in here and you should probably try to find a way to make the integration happen the other direction.

integration/
	- Meant for providing the code to integrate with external utilities for sharing data and analysis in either direction.
		- barnyard2 integration is currently the only example for this.
	- Can load utils and frameworks
		- In rare cases, can load protocol analyzers (think of using the syslog analyzer to actually collect logs at runtime)
		- Yes, Bro is now a syslog server in a very real sense. :)  I need to write a script that really shows this off and the analyzer needs improved a bit (i.e. TCP support), but I think that we could even carry this over and run clustered syslog setups with broctl.

protocols/
	- These are scripts that do protocols analysis by handling protocol specific core generated events and most of them build some amount of reusable state in the connection record.
	- Can load utils and frameworks.
	- Ok to load other protocol specific scripts if needed for analysis of the protocol.

misc/
	- Mostly for non-protocol analysis related functionality that may be desired but it's not meant to be reusable from a programming perspective (i.e. loaded-scripts.bro that logs which scripts were loaded).
	- Can only load utils and frameworks.
	- Not to be loaded by other scripts.  

tuning/
	- only doing redefs.
	- Don't @load anything.  Dependencies should already be loaded.

utils/
	- These are all utility functions that are nice to have in many cases and can be used in a number of ways.
	- Only functions.
	- Can only load other things in utils/


Thanks!
  .Seth

--
Seth Hall
International Computer Science Institute
(Bro) because everyone has a network
http://www.bro-ids.org/