packaging some POC-seen scripts for the intel framework I was wondering what would be the preferred granularity of Bro packages. In case of seen scripts, it feels extreme to generate a package for every script.
So one approach would be to group them into a single package and let the user load the single scripts on demand. But, some of the scripts might depend on other packages. These packages would be suggested during install. Assuming a minimal install this could lead to a couple of scripts, that spit errors if loaded. So if someone decides to load the scripts later, he or she might forgot about the dependencies. In that case it would be nice if one could check either for the availability of certain identifiers (lookup_ID didn't work for me due to type clash in comparison) or a package.
packaging some POC-seen scripts for the intel framework I was wondering
what would be the preferred granularity of Bro packages. In case of seen
scripts, it feels extreme to generate a package for every script.
Might depend largely on the judgement of the packager, though I think
the train of thought will end up being similar enough to provide
guidelines like the following:
If you think other packagers would depend on your scripts: it probably
is better to provide separate packages where each offers the minimal
feature set that one would expect to depend upon.
If you don't think other packagers would depend on your scripts, then
it may make sense to start with a single monolithic package, depending
on what you think would be the best thing for your users. A deciding
factor/question here could be "does the package have a performance
impact by default". If no, a single package for multiple different
APIs/features could work alright. If there are performance hits just
by installing/loading the package, then it may be easiest for you to
separate out those areas that require extra cpu utilization into
distinct packages, or else you'd need to provide a user with a set of
options (&redef's) that they can use to toggle different features of
the monolithic package.
case it would be nice if one could check either for the availability of
certain identifiers (lookup_ID didn't work for me due to type clash in
comparison) or a package.
Would the @if, @ifdef, @ifndef directives (e.g. for preprocessing away
whole chunks of code) work for what you were trying to do?
There's also maybe the `bro_script_loaded` event you could use to set
a global flag and then branch on that in later code paths.
Might depend largely on the judgement of the packager, though I think
the train of thought will end up being similar enough to provide
guidelines like the following:
If you think other packagers would depend on your scripts: it probably
is better to provide separate packages where each offers the minimal
feature set that one would expect to depend upon.
That's a good rule of thumb I think!
Would the @if, @ifdef, @ifndef directives (e.g. for preprocessing away
whole chunks of code) work for what you were trying to do?
I finally decided to use a @ifdef construction in __load__.bro, which seems to be the best fit for now.