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,
—octo
--
collectd – The system statistics collection daemon
Website: http://collectd.org
GitHub: https://github.com/collectd
Twitter: http://twitter.com/collectd
_______________________________________________
collectd mailing list
collectd@verplant.org
https://mailman.verplant.org/listinfo/collectd
