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

[Nick Babcock]

I think it makes sense to support Go plugins. While I can't speak about Go directly, maintaining a Rust crate [0] for creating collectd plugins over the years has taught me that there are some benefits to out-of-band plugins compiled to shared objects:

- More rapid plugin releases (especially new plugins) that don't need to be tied to the main release
- Being able to have a plugin target collectd versions prior to its existent. For instance, the rust crate allows one to compile to a shared object that is compatible with either 5.4, 5.5, or 5.7+'s collectd plugin API. So in effect, new plugins can be backported to older collectd installations.

I don't know if those are in accordance with your thoughts, but I feel like allowing Go plugins could also lower the barrier to entry for contributors.

Thanks
-Nick.

[0] https://crates.io/crates/collectd-plugin
________________________________
From: collectd <collectd-bounces at verplant.org> on behalf of Florian Forster <octo at collectd.org>
Sent: Thursday, April 23, 2020 1:29 AM
To: collectd at verplant.org <collectd at verplant.org>
Subject: [collectd] RFC: Should we maintain plugins written in Go?

Hi everybody,

TL,DR: Should we create a new Git repository and maintain plugins
written in the "Go" programming language?

the last days, I spent some time improving the "collectd.org/plugin"
package [0]. In a nutshell, it allows to implement a plugin in Go,
compile it to a shared object and then load it like other "native"
(implemented in C) plugins. The primary benefit over approaches such as
the "collectd.org/exec" [1] and "collectd.org/rpc" [2] packages is, that
it supports implementing "write" and "log" callbacks. "config"
callbacks, allowing one to configure the plugin via the collectd config
file, are work in progress.

My question is: Should we attempt to maintain plugins written in Go? And
if so, how?

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.

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.

Best regards,
—octo

[0] https://godoc.org/collectd.org/plugin
[1] https://godoc.org/collectd.org/exec
[2] https://godoc.org/collectd.org/rpc
--
collectd – The system statistics collection daemon
Website: http://collectd.org
GitHub:  https://github.com/collectd
Twitter: http://twitter.com/collectd

_______________________________________________
collectd mailing list
collectd at verplant.org
https://mailman.verplant.org/listinfo/collectd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20200425/8ea9e71b/attachment.html>