I’m considering restructuring my baroc files so that I
have a separate file for each event class, for documentation purposes. Whenever
possible, I prefer to embed documentation into the thing I am documenting
(scripts, rulesets, etc) so that it all stays together. It drives admins crazy
when they come across a shell script with what appears to be a web page
embedded in the comments, but I find it’s easier to maintain that way.
For TEC rules, each ruleset file has its web documentation
embedded in comments. Obviously, if I put each rule into its own file, that
would effect how the rules are processed (specifically the commit_*
predicates), so I keep them together in their original ruleset files. However,
for event classes, I really want a separate html file for each event because
these are what the TEC console “Information” button ultimately
displays. Clearly, I could still keep all the classes grouped together in their
original files and separate them out when I run my script to generate the html
files, but I think it might be cleaner to just put each one in its own file to
begin with.
I am thinking that there should not be any reason why it
would make any difference to the event server whether I define 100 event
classes in one big file or in 100 small files. It might cause the compile/load
process to take a bit longer, due to the overhead of opening more files, but I
could live with that (unless it opens them all simultaneously). I wouldn’t
expect there to be any impact on the event server startup time under normal
circumstances (in fact, after compile/load, you can delete the entire
TEC_CLASSES directory(s) and TEC does not seem to notice until the next time
you compile/load).
The only gotcha that comes immediately to mind is the
.load_classes file. Could there be some sort of arbitrary limit to the number
of lines allowed in that file? It’s hard to imagine, but stranger
things have happened.
Anyone tried this?
Loren Cain
Digicon
