> On Jun 5, 2016, at 10:55 AM, Robin Sommer <[email protected]> wrote:
>
> So what if we stepped back
Yes, generally we may need to step back. I think this thread started based on
the idea that the names of things are entirely subjective and separate from the
technical design. But that’s not true — I need to be able to write unambiguous
documentation and the choice of using plugins as the top-level container type
means that introducing any other name for that container is creating an
ambiguity. So yes, we can revisit the choice to use plugins as the top-level
container.
> and ignored how we will represent/structure
> these things internally and just conceptually adapt the model Jan is
> describing: we're creating *new* containers that support both scripts
> and plugins, and CBAN manages these containers
Yes, that could be a way to do things if I understand it right as:
- New Container
- Script Container (e.g. what is currently called “script package”)
- Compiled Code Container (e.g. what is currently called “plugin”)
Another idea is to not have any new container and allow the Script Container
and Compiled Code Container to live at the top of the hierarchy as siblings. I
think they could still share a common metadata format. It would also still be
possible for a person to promote their Script Container to a Compiled Code
Container if they find that they need that level of functionality.
> (As a side node, bringing "bro -N" into the picture makes things even
> more confusing because that's *really* targeting the binary extension
> stuff. For example, "-NN" wouldn't show the script code being added).
Yeah, I see how that’s a bit messy now, but skeptical because it might not be
much of a fuss to just change/improve the output of a command line argument.
> On Sat, Jun 04, 2016 at 21:23 +0000, Adam wrote:
>
> If a wrote new Python module
> implementing, say, BASE65 encoding, I wouldn't be adding a "plugin" to
> Python either.
Correct, you didn’t write a plugin to Python, but if you had an application
called "Foo" that allows users to specify custom encoding schemes via Python
scripts, then you wrote a plugin for “Foo”.
So while a Bro script isn’t a plugin for the Bro language, it is a plugin for
the Bro application.
> A "plugin" typically
> plugs into a set of hooks that a software provides to extend things it
> doesn't provide out of the box; once loaded, that new functionality
> then becomes a core feature just as if it had been built in in the
> first place. I don't see, e.g., writing a script-level detector for
> new vulnerability XYZ like that.
But writing such a script does extend Bro w/ new functionality that it doesn’t
provide out of the box, so it seems to fit your definition of a plugin as well.
The only difference I see is that a script is more limited in how far it can
extend functionality, but that’s not a binary property you can use to easily
categorize plugin vs. non-plugin.
The way I see it: one set of “plugin hooks" that the Bro application provides
is the Bro scripting language itself and all the APIs/BIFs/events that are
available within it.
> On Sun, Jun 05, 2016 at 15:09 +0000, Jon wrote:
>
>> My argument is that it is true/factual/objective that scripts may used as a
>> form of plugin.
>
> Yes, but per above that's only because we decided to reuse the
> internal structure. To me, that's arguing from an implementation-level
> artefact, which isn't good starting point for defining terminology.
But I’m not just arguing based upon the way Bro’s plugins are implemented, I’m
arguing about plugins in general. There exists applications that use scripts
as a form of plugin.
So I’m saying it’s actually a Good Thing that Bro plugins can be script-only or
additionally use compiled code, even if it was not intentional because it fits
an even wider description of the term “plugin”.
But if you still don’t like that plugins can be used for scripts-only, then we
should probably revisit the design so that we aren’t using them in that way
(e.g. the ideas presented near the top of this email).
>> And that task isn’t even difficult. It takes a single sentence
>> description: “Bro Plugins can be either compiled code, Bro scripts or
>> a combination of both”.
>
> Sure, but it's still confusing to tell people you need to write a
> plugin to add your new vulnerability detector;
They only need to write a plugin if they plan to distribute it so that it works
w/ the new plugin manager tool. I don’t see how that can lead to confusion,
but I do see how maybe that could be more tedious than they would like :)
We can address this problem by designing the manager to seamlessly deal with
both script-only containers as well as compiled-code containers like we were
thinking about above.
> whereas so far they
> simply wrote a script. Look at the mailing list for how people have
> used the term "plugin" so far: I'm pretty sure it's been only about
> binary plugins.
But that doesn’t negate the truth that plugins currently may be either
script-only or binary. And those past discussions don’t become invalidated if
we move to using script-only plugins more generally.
> Nobody writing just a script has said "I have a
> question about my plugin”.
Because at the time they said that, they weren’t authoring a plugin, they were
writing a script :)
People don’t currently have a reason to put their scripts inside a plugin, so
that’s why no one uses that wording and goes down that path. The incentive for
them to start putting their script within a plugin would be the existence of a
tool that manages plugins as a top-level container.
I think it may be worth it to do another design pass to see if can find any
problems w/ either the super-container or sibling-container approach as
outlined at the top. I do like those ideas and only see improvements and no
drawbacks (apart from implementation code complexity, which doesn’t count for
much), so I don’t mind wrapping my head around it for a bit longer to see if
it’s a better fit. Unless I’ve convinced you that “plugin” as the top-level
container is the way to go?
- Jon
_______________________________________________
bro-dev mailing list
[email protected]
http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
