[collectd] RFC: Should we maintain plugins written in Go?

[Matthias Runge]

On 23/04/2020 08:29, Florian Forster wrote:

> 
> For Go-based plugins, i.e. plugins based on "collectd.org/plugin", I
> propose we create a separate repository, e.g.
> github.com/collectd/go-plugins, and maintain those there. This would
> make plugins easier to discover for users, allow easier changes to the
> API, and strive for consistency across the ecosystem.
> 

Hi,

thank you for starting this thread. I like the idea to start something
new here. Given the nature of plugins written in go, it totally makes
sense to keep them separate. Maybe that would also lower the entry
barrier for new plugins.


> In the past, we have imported plugins in non-C languages into the main
> repository, in particular bindings/perl/ and bindings/java/. This model
> is not a good fit for Go, which makes much more assumptions about the
> directory structure of a repository. Also, for Perl and Java the "glue
> code" (code translating between Perl and Java, and C) is contained in
> the "main" reposiroty; that's not the case for Go.
> 
> I'm also contemplating if we should try to support plugins using the
> "exec plugin" more, e.g. by creating a repository for them. There are a
> number of "collectd Docker" plugins and I feel like this duplication
> could have been avoided by better discoverability.


While I also like the idea to provide a "repository" for exec plugins,
or a list of exec plugins, I wonder if we would like to add any
limitations? Would we "support" an exec plugin written in scheme? What
would it mean, if a plugin is included in the repository. Would we care
about it? Would we fix a bug, a CVE?

Matthias