> On Jun 6, 2016, at 10:01 AM, Vlad Grigorescu <[email protected]> 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 _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
