The problem we're trying to solve is how to best organize the packages
under protocol/ such that there's a way to load them without a possibly
unwanted side-effect of loading an entire package under frameworks/
because one script happens to require it (is that right Seth?).
Correct.
e.g. we want "@load protocols/http" to avoid loading frameworks/software.
Why don't we just write the __load__.bro manifest of the package to not @load scripts that may have unwanted side effects? The __load__.bro that
gets loaded implicitly is already provided only for convenience and may
not actually load the entire contents of the package.
The __load__.bro scripts are actually where I would be hiding these extra dependency based loads. I was just looking for a way to reduce dependencies without having to add code to manage things manually. For example, I'd like packages to offer the ability to do something with the software framework if it's available, but if it's not available to just not load the functionality.
I'm starting to recognize that I'm looking to do something like dependency injection but perhaps we're still a bit early on in the modularization of Bro scripts for us to figure out how to do this well. If everyone's onboard we can just table this discussion for now and I can do this more manually, I may even be able to rig up a dependency injection-like framework in script-land.
I would still really like the relative path based loading though, it's really painful to do inter-directory script loading right now and it would be a bit difficult for others to contribute external scripts and manage them well because the full path is used for loading.
3) the "I don't care how much extra stuff gets loaded, give me everything
in the package" approach via "@load protocols/http/*" to recursively
load all files that have a .bro extension (skipping __load__.bro)
I'm not sure this is a good option as I have written a couple of things where you would never want to load everything and loading everything could actually lead to disaster (or at least broken-ness).
example, I'd like packages to offer the ability to do something with
the software framework if it's available, but if it's not available to
just not load the functionality.
It seems like that approach is well-intended at making packages appear
more modular, but weren't the solutions we came up with taking away
from a user's ability to control what scripts get loaded?
For example, what if a user wants the ssh package's software-related
scripts to load, but not the http package's software-related scripts?
I'm starting to recognize that I'm looking to do something like
dependency injection
Dependency injection patterns are more for object-oriented languages, no?
but perhaps we're still a bit early on in the
modularization of Bro scripts for us to figure out how to do this
well. If everyone's onboard we can just table this discussion for now
Yeah, we might wait. I'm not fully convinced that the way you currently
organized things actually has a modularity problem that significantly
hinders a user's ability to use bro.
I would still really like the relative path based loading though
Yeah, I didn't have any problems with that new feature.
It seems like that approach is well-intended at making packages appear
more modular, but weren't the solutions we came up with taking away
from a user's ability to control what scripts get loaded?
For example, what if a user wants the ssh package's software-related
scripts to load, but not the http package's software-related scripts?
Yep, agreed on both counts. I had kind of identified the "globally enabled functionality" problem myself internally, but was reluctant to admit it to myself because in the case of the software scripts it should cause very little overhead. It does cry out for a more generic solution though that leaves control in the users hands.
Dependency injection patterns are more for object-oriented languages, no?
Yeah, I think you're right.
but perhaps we're still a bit early on in the
modularization of Bro scripts for us to figure out how to do this
well. If everyone's onboard we can just table this discussion for now
Yeah, we might wait. I'm not fully convinced that the way you currently
organized things actually has a modularity problem that significantly
hinders a user's ability to use bro.
At least we're slowly getting somewhere and sometimes by choosing *not* to do things.
Sorry for being the party pooper now but I *do* like the ability to
load something automatically (only) when something else is loaded as
well. I don't think that can really be substituted for at the
scripting layer right now, at least not nicely. software.bro is a good
application for that and I'm sure there are more (like the
intelligence framework?).
We need to bring the current prefix mechanism back to live anyway (and
with the new load order I think), and this would be quite easy to add
on top of that if I'm not missing anything. So why don't we give it a
try and see if it works for what's it's supposed to help with.
Sorry for being the party pooper now but I *do* like the ability to
load something automatically (only) when something else is loaded as
well.
Haha, I don't think it's possible for you to be the Bro party pooper. You're the life of the party!
I don't think that can really be substituted for at the
scripting layer right now, at least not nicely.
I'll think about this. It may be possible to make something fairly clean at the scripting layer.
software.bro is a good
application for that and I'm sure there are more (like the
intelligence framework?).
Yep, the intelligence framework is another big one. The metrics framework may be another one as well, but possibly not. I'm not sure of how exactly it will be used yet.
We need to bring the current prefix mechanism back to live anyway
(and with the new load order I think), and this would be quite easy to add
on top of that if I'm not missing anything.
In my mind I saw the new implementation of @prefixes as independent of that
"@add x when y" idea. There's some similarities in how they work, but they
don't depend on each other.
So why don't we give it a try
For now I'll attempt these changes:
- allow relative paths in @load's, e.g. "@load ./software"
- new @prefixes implementation
I'll put these off due to contention:
- allowing '.' vs. '/' in package names
- "@add x when y"
