[Bro-Dev] CBAN naming

[Siwek, Jon]

> On Jun 6, 2016, at 10:01 AM, Vlad Grigorescu <vlad at grigorescu.org> wrote:
> 
> 2) From a developer's perspective, submitting to "CBAN," maintaining and updating their code should be as painless as possible. Let's not forget that at the end of the day, the only thing that matters in making this project successful or not is developer contributions. If people aren't contributing, none of this has any point.
> 
> The first goal is the reason we moved away from bags and carts. However, I think we're in danger of straying too far away from the second goal. I think having containers which manage both scripts and plugins would be a mistake.

Yeah, we do need to keep the goal of making things easier for devs/authors, but I’m wondering if having the top-level containers be plugins doesn’t actually make things a harder for people who were only writing scripts to begin with?

They now have to learn what a plugin is and how to make one instead of just being able to ship their directory full of scripts and have it work.  Let me know what you think.

> A scenario that I see as being quite likely is that a developer starts such a container as being script-only, but wants to expand it at some future date.

I’m following Matthias on this in that I see such a super-container at the top-level being able to deal w/ changing from script-only to scripts+compiled in a way that’s transparent to users.  We may also want a form a pinning that allows a user to say “don’t upgrade this if it changes from script-only to compiled code”.

You had some good implementation detail questions about how to make this work well that I think all have answers, so in interest of keeping the thread shorter I won’t go in to them now.  But let me know if you see one problem that will be particularly tricky that we should go into detail about.

> I believe that any issues with the name of "plugin" versus "package" can and will be quickly cleared up when the project is released. I'll note that the script plugin component is actually the only one currently documented here: https://www.bro.org/sphinx-git/devel/plugins.html 

Yeah, I’ll concede maybe people will get used to it, but I at least need to be working from a design spec that tells me exactly what to do concerning that page.  If we start using “package” in one place I will eventually need to start talking about how a “plugin” works and refer to that page, which is currently a user-facing doc.  Do canonicalize it to use “package”? Do I leave it alone and just have a non-sequitur transition in talking about “packages” and then suddenly “plugins” ?

If we switch the design to instead user the super-container format, then that’s not an issue for me anymore because the relationship changes from “is a plugin” to “may have a plugin”.

- Jon