[collectd] RFC: Should we maintain plugins written in Go?
octo at collectd.org
Mon Apr 27 19:11:03 CEST 2020
thank you very much for your perspective! I wasn't previously aware of
the collectd-plugin crate, thank you so much for creating it!
De-coupling plugin releases from daemon releases was something that we
discussed for C-based plugins, too. Unfortunately detangling those
plugins is quite a bit of work.
The Go code depends on some collectd-internal symbols, likely very
similar to the Rust crate. I don't currently plan to support ancient
versions of collectd, but I routinely build against 5.8, the version
shipped by Debian. While the abstraction is certainly leaking through
into Go, many C API changes can probably be hidden, resulting in a
stable Go API.
Speaking of the above, the daemon should export a "version" symbol so
that the ABI/API can be determined at runtime. Not sure if we should go
full ABI-versioning, but I'll open a bug so we can discuss there.
Lowering the barrier to entry is certainly an important aspect. Go is
especially strong when talking to REST- and other web-based APIs, which
are very popular with the kids these days ;)
All the points we discussed so far equally apply to Rust-based plugins.
Could / should these live in a "rust-plugins" repository under the
collectd – The system statistics collection daemon
More information about the collectd