Related to “pkg” or “package” naming: if that terminology gets used, what would be done about the classic/existing usage of the term “package” within Bro?
“Package” is currently used to refer to any collection of Bro scripts within a common directory. Just scripts, nothing else. Meaning a “package”, as it exists now, isn’t something that the new "package manager” would know how to deal with.
I don’t think it’s a good idea to let the term be overloaded in the documentation and possibly internal naming conventions in Bro code. Not that it can’t be changed, but just wondering if it’s already been decided that making those changes would not be a big deal.
It looks like that term is just used here for “Script packages” and on all the auto generated subpages. We can just rename that as I don’t it is not a widely used term. I do want to do that before 2.5 if we do it, though.
So with that said, I propose bro-pkg, but will leave this open for another day if there are strong opinions.
So with that said, I propose bro-pkg, but will leave this open for
another day if there are strong opinions.
I like "bro-pkg," though I wonder whether it could be even shortened to
"bpkg" or "bkg." This would be the name for the command line client.
How would we call the whole thing? The Bro Package Manager? Or asked
differently, what would be the replacement name for CBAN? Personally, I
think nothing speaks against BPM (even though there exists a bpm-tools
Linux package) since we're not using it as the name for the executable.
I like "bro-pkg," though I wonder whether it could be even shortened to
"bpkg" or "bkg."
It could be, and bpkg is what I original suggest, but I thought you and Justin liked bro-org better.
The point here was that bro-pkg would align to bro-cut. Although I still
like brow, I would prefer bro-pkg or bropkg to bpkg and bkg. While
b(p)kg could be anything bro-pkg is clearly bro-related.
Collections of bro scripts in a directory containing an __load__.bro file were named “packages” because that is pretty much the same way Python structures the things it calls “packages”. So, now that I think about it, it’s actually more odd to rename them because that structural similarity is not going away.
Maybe I value consistency too much, but I don’t see how any of the proposals so far are improvements to the current situation. I’m going to make a final argument for just sticking with the original names of things:
1) Keep calling “Bro Script Packages” as “packages”. They look just like Python packages after all.
2) Keep calling “Bro Plugins” as “plugins”. No one explicitly asked to rename plugins or give them an alternate name, but that is what is happening here whether people realized it or not. Why are we trying to create a synonym for something that is already called a “plugin” ? Won’t it be more confusing if it turns out that a “package” may also be called a “plugin” ? And confusing that a “package" (also called a “plugin”) shares little similarity with a Python package, but it contains within it something that does look like a Python package, yet is named something else?
3) CBAN becomes something like “Bro Plugin Manager” because it is dealing with plugins, not packages. In fact, “plugin" is probably more descriptive about what is going on. In general, a plugin just means any form of extending a software’s functionality without having to directly modify that software. That could mean shared libraries, scripts, etc. This is exactly what is going on here and I don’t see how we can get any more clear or consistent than the existing names.
So what would you do, call it the tool bro-bpm, the project “Bro Plugin Manager” (BPM), and the objects being managed plugins?
Alternatively, what I earlier proposed is that we call directories of related scripts bundles, plugins are called plugins, a plugin+metadata that fits them within our package manager a package, and the whole system the Bro Package Manager (BPM) with the tool named bro-pkg.
I am fine if we want to hash out these last two options a bit longer, but please no more to the mix.
I like this idea better than anything else I've heard so far, but
one small issue is we would need to be a bit careful to distinguish between "Bro plugins" (as seen by running "bro -N"), and
"Bro plugin manager plugins" (as seen by running "cban list").
Not sure if this would actually cause any real confusion,
just wanted to raise the issue. After all, the meaning of words like
"package" already depends on the context (e.g., "I installed the Bro rpm package" vs. "I installed Justin's passive DNS script package from
github").
3) CBAN becomes something like “Bro Plugin Manager” because it is dealing with plugins, not packages. In fact, “plugin" is probably more descriptive about what is going on. In general, a plugin just means any form of extending a software’s functionality without having to directly modify that software. That could mean shared libraries, scripts, etc. This is exactly what is going on here and I don’t see how we can get any more clear or consistent than the existing names.
From my perspective scripts do not extend Bro. Scripts get executed by
Bro to provide extended functionality. Calling Bro-scripts plugins for
Bro is somehow like calling python-scripts plugins for the python
interpreter.
Alternatively, what I earlier proposed is that we call directories of related scripts bundles, plugins are called plugins, a plugin+metadata that fits them within our package manager a package, and the whole system the Bro Package Manager (BPM) with the tool named bro-pkg.
I really like that naming. What should also be defined in that context
is the term module. My understanding is that a module is a functional
unit that groups script-layer functionality (defined by scripts or
plugins) in a dedicate namespace.
Regarding the discussion about the term "package" I recommend not to
think too much about details of other software and its implications for
that term. A package is "a wrapper or container that covers or holds
something" [1]. Some people might assume that a Bro-package looks like a
python-package. But Bro is not python so their assumption might be wrong
So what would you do, call it the tool bro-bpm, the project “Bro Plugin Manager” (BPM), and the objects being managed plugins?
Yeah both the tool and the project are "Bro Plugin Manager” (or some variant of BPM abbreviation) because that is role they perform. The Bro Plugin Manager repository contains a Bro Plugin Manager client as well as a central location for plugins contributed by the community. i.e. the client helps manage a particular user’s plugins and the repository helps manage/organize the whole community’s plugins.
Alternatively, what I earlier proposed is that we call directories of related scripts bundles, plugins are called plugins, a plugin+metadata that fits them within our package manager a package
My last understanding is that we’re starting out w/ metadata being entirely optional and seeing how it goes. This also makes it more convenient for people to use the tool to manage plugins they have no intention of publishing and so don’t care to bother w/ metadata.
So my opinion is that there is no reason to uniquely distinguish plugin+metadata from a regular plugin. Besides that, adding metadata to a plugin doesn’t change the fact that it is still a plugin that can be used directly with bro without requiring the use the new “plugin manager” at all.
My view is that “bro -N” gives you a list of “installed” plugins and “bpm list” gives a list of “available” plugins. In both cases, it’s still giving lists of plugins, but just filtered differently.
A difference is that Python is a general purpose language and Bro is not. So I agree, it’s weird to call python scripts plugins because they don’t really extend Python itself. But Bro scripts are intended extend Bro’s functionality (you even said so yourself :)), so it’s not weird or false that they can be categorized as a type of plugin.
I still strongly disagree with ALL metadata being optional, unless it is automatically cleaned up if they never “finish” putting in required data.
However, that does not have a large impact on the name. I think we are now arguing between two reasonable proposals, and I am fine giving preference to the plugin naming because it does require the least amount of changes in current naming conventions.
I will leave it open this weekend for members of the project leadership to jump in if they want, but otherwise let’s go with Bro Plugin Manager (BPM) and bro-bpm.
I still strongly disagree with ALL metadata being optional, unless it is automatically cleaned up if they never “finish” putting in required data.
Sorry, I was just talking about in terms of interoperability w/ the client: all metadata is optional and doesn’t magically turn a plugin into something else that can now work with it. A goal for repository submissions is to have some quality checks in place to enforce some minimum metadata to be there.
I am fine giving preference to the plugin naming because it does require the least amount of changes in current naming conventions.
Right, but just to succinctly summarize all the reasons that I think point toward any form of “package” being used for this project as a poor choice:
- it's too generic and not useful in describing what it is/does (in contrast to “plugin”)
- it would create another term for what is already named a “plugin”. Having two words for the same thing isn’t optimal.
- the term is already in use within Bro for script packages
- it's also already overloaded based on other contexts (e.g. binary packages)
I will leave it open this weekend for members of the project leadership to jump in if they want, but otherwise let’s go with Bro Plugin Manager (BPM) and bro-bpm.
Yes, I’d go with that, too.
On the exception that someone can come up w/ a longer list of convincing problems regarding the use of “plugin”
Sorry, I have to keep the discussion going by objecting.
I really don't like calling these things "plugins", nor calling the
whole thing the "plugin manager". I'm with Jan here: I think that
would be quite misleading in terms of what I believe people associate
with "plugin" normally and also with how we've used the term "plugin"
so far. The primary way we've used "plugin" so far is as a compiled,
binary extension. While indeed the structure also accommodates
script-only plugins, that does not warrant calling a set of scripts a
"plugin" in my view. Indeed I don't think most people even realize
that a plugin can be just scripts.
In contrast, "package" is much more generic and can therefore better
accomodate a range of things without becoming confusing (it's fuzzy to
begin with So my vote goes to "package", "bro-pkg", and "Bro
Package Manager". We could then also start calling the script-only
things "modules", which aligns with what the scripting language
already does with its namespaces (and in fact I'm often using "module"
in that way already). So a "package" would then contain script
"modules" and/or binary "plugins"
My second choice would be using "bundle" instead of "package", and
then I guess "bro-bundle" "Bro Bundle Manager". We're introducing
something new here, so it would make sense to use a new term, "bundle".
Sorry, I was just talking about in terms of interoperability w/ the client: all metadata is optional and doesn’t magically turn a plugin into something else that can now work with it.
[...]
- it would create another term for what is already named a “plugin”. Having two words for the same thing isn’t optimal.
Just a side note: If we equalize the concept of a plugin/script with the
concept of a bundle/package, I agree that it would be unnecessary to
find a new name for the same thing. But to me a bundle/package is
something different: It's a deployment unit, acting as some sort of
container (usually enriched by metadata). A plugin/script itself could
be used with Bro but wrapping it into the container allows to manage it
(e.g. in terms of version, dependencies, etc.).
I'm not sure we all have or that the project has used it consistently in that way. It is new enough to Bro I'm not bothered if we shift it slightly. To me, the important part of a the definition of a plugin for most software is that it is an externally contributed, self/contained add-on which extends functionality. Binary or compiled don't seem very important to the definition.
Module, extension, package, bundle, add-on, plugin, bag, etc.; whatever we pick long term users will acclimate. I am more concerned new users or creating confusion in our documentation.
So are you saying that the "bpm" command wouldn't have a way to show all plugins
that were installed via the bpm command? I assumed that is what "bpm list"
would show.
