# Script reorg proposal **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [August 1, 2011, 4:49pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953 "2011-08-01T16:49:19Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [August 2, 2011, 4:45pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/21 "2011-08-02T16:45:18Z")
> structures), I found myself often replacing entire chunks of the base > code by means of substituting implementations. Maybe this strategy is > not apt anymore after the script reorganization and the new logging > framework?! I don't have enough experience with the old scripts to compare, but I find that Seth did a great job at creating lots of points in the new scripts for extensibility. - Jon ---
**Author:** ![Jonathan\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/e68b1a/32.png) [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)\ **Post date:** [August 2, 2011, 5:48pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/22 "2011-08-02T17:48:55Z")
> > > having to go from-all-to-nothing. Then we could also just use a single > > > (base) directory for all the scripts instead of bro/base and bro/policy > > > (which kinda irks me). > > > > One of the main motivations for the proposed reorg is actually to > > split the two apart. Currently, they are all inside one directory > > hierarchy, but that makes it hard to get a good picture of what's > > there. > > I think that needs to be solved by documentation. Have some (short) doc > that lists everything that's @load'able and briefly describes what it > does.(1) My preference would be for the "optionality" (or probably even functionality) of a script/package to be implied by where it lives in a directory hierarchy. The documentation would naturally also reflect this without extra work (probably). The difference is that if everything lives under a common hierarchy, I 'm forced to consult some additional documentation/manifest in order to understand what parts are optional instead of just being able to know when I'm poking around in a shell. > So this top-level.bro is basically the same as my default.bro except it > lives in base/, right? So what's the advantage? That it's easy to see > what's loaded by default based on the directory where the script is? Yeah, that's my impression of what the main advantage is. > If that's indeed the case and you want to do the split into two > directories, I would still advocate to do top-level.bro the way I > described my default.bro, i.e., but it in /site and add comments to make > it "user serviceable" 🙂 I think this is what the site/local.bro currently does, and I generally like that way of doing it. > Another question would be whether one would split protocol analysis > between base and policy? E.g., is there going to be "base/http/" and > "policy/http" and when I load the first as package I get the basic and > when I also load "policy/http" as package I get the heavier analysis or > would I also cherry-pick additional features in "policy/http/\*"? Yes, both packages could exist, base/http for basic analysis and policy/http for advanced. In the later case, my feeling is that cherry-picking is always allowed/encouraged, but if we allow policy/http to be loaded as a whole package, we might need some convention that makes that behavior well-defined or inferable from the naming/hierarchy for the cases where a package contains related-but-conflicting scripts that shouldn't be loaded together and thus require cherry-picking. If that situation occurs, my suggestion would be to use an opt/ subdir of a given package to reflect such add-on scripts that require the user to do a little thinking before loading it. - Jon ---
**Author:** ![Matthias\_Vallentin1](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/matthias_vallentin1/32/596_2.png) [@Matthias\_Vallentin1](https://community.zeek.org/u/Matthias_Vallentin1)\ **Post date:** [August 2, 2011, 7:23pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/23 "2011-08-02T19:23:53Z")
(Thanks for the elaborate summary on filesystem paths! I am on the same page.) > Our current approach might be adequate since the admin has an easy way > (change default BROPATH) to choose the best place for their local > files. Yup, the current approach appeals to me as well. Rethinking the introduction of ~/.bro, I am not sure whether it adds more complexity or helps newcomers. When in doubt, it's always good to avoid feature creep.     Matthias ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [August 2, 2011, 7:55pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/24 "2011-08-02T19:55:34Z")
> > Another question would be whether one would split protocol analysis > > between base and policy? E.g., is there going to be "base/http/" and > > "policy/http" and when I load the first as package I get the basic and > > when I also load "policy/http" as package I get the heavier analysis or > > would I also cherry-pick additional features in "policy/http/\*"? > > Yes, both packages could exist, base/http for basic analysis and policy/http for advanced. In the later case, my feeling is that cherry-picking is always allowed/encouraged, but if we allow policy/http to be loaded as a whole package, we might need some convention that makes that behavior well-defined or inferable from the naming/hierarchy for the cases where a package contains related-but-conflicting scripts that shouldn't be loaded together and thus require cherry-picking. If that situation occurs, my suggestion would be to use an opt/ subdir of a given package to reflect such add-on scripts that require the user to do a little thinking before loading it. Yeah. I think users should have to cherry-pick individual scripts form policy/\* and not be able to load them via packages. cu gregor ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [August 2, 2011, 8:09pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/25 "2011-08-02T20:09:34Z")
That's the plan. This is nice, everyone that has commented on this thread really seems to either be in complete agreement or very nearly complete agreement across the board.   .Seth ---
**Author:** ![Gregor\_Maier](https://avatars.discourse-cdn.com/v4/letter/g/94ad74/32.png) [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)\ **Post date:** [August 5, 2011, 2:53am UTC](https://community.zeek.org/t/script-reorg-proposal/1953/26 "2011-08-05T02:53:21Z")
Another comment probably related to this: When looking through the automatically generated script documentation I was at first confused because I clicked on say: protocols/conn, when I was actually interested in protocols/conn/base. I guess the reorg should help with that too. Otherwise we might want to consider if we can make this easier for users.... cu gregor ---
**Author:** ![Seth\_Hall3](https://avatars.discourse-cdn.com/v4/letter/s/d6d6ee/32.png) [@Seth\_Hall3](https://community.zeek.org/u/Seth_Hall3)\ **Post date:** [August 5, 2011, 4:16am UTC](https://community.zeek.org/t/script-reorg-proposal/1953/27 "2011-08-05T04:16:05Z")
Yep, it should help quite a bit. I think we can probably start collecting feedback on the optimal way to organize the logs for Jon after the reorg is finished (hopefully very soon!). I agree that it's important and needs to be user focused.   .Seth ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/script-reorg-proposal/1953/28 "2022-05-06T15:39:42Z")
Closed on May 6, 2022, 3:39pm UTC [Previous page](https://community.zeek.org/t/script-reorg-proposal/1953.md?page=1)