Hi Nick,

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" organization?

Best regards,
collectd – The system statistics collection daemon
Website: http://collectd.org
GitHub:  https://github.com/collectd
Twitter: http://twitter.com/collectd

collectd mailing list

Reply via email to