Crazy thought: what if I added another request handler language to #iocaine? What if it was #Rust?
Not quite sure how it would work, but the request handler would be a crate-type = ["cdylib"] thing. That might be even more performant than Roto, and would allow doing a whole lot of things neither the Roto nor the Lua/Fennel engines can (because they're intentionally locked down, while due to the nature of being a cdylib, Rust wouldn't be).
...or perhaps just dylib, because I don't need ABI stability between Rust versions, and I don't need (nor want) non-Rust modules.
Regardless of the outcome of this thought experiment, Nam-Shub of Enki will stay Roto, because it is fast enough, can do just about anything I want, and unlike a Rust plugin, it is locked down.
However, there's another area where plugins could be useful: exposing more things to Roto & Lua/Fennel. I can also see a few more places where this could be useful.
This is strictly post-3.0 material, though. Probably not 4.0, because as far as I can tell right now, after having spent about 15 minutes pondering about it, I should be able to add a new language and plugin-extensibility for the existing ones without it being a breaking change.
I do not like breaking change, and I'm annoyed at my lack of foresight that iocaine is already about to be 3.0 while being only what... 8 months old?
My last project (riemann-c-client) that used SemVer and reached 1.0 took almost 9 years to go from 1.0.0 to 2.0.0. Naturally, half of the Linux distros are still on 1.10 (released in 2021).
(Little flex though, regarding riemann-c-client: I did have to break ABI once, for 2.0, but I managed to preserve the API. A program written for riemann-c-client 1.0.0 should compile and work with 2.2.2 without changing anything.)
With 3.0, one of my goals is to drastically reduce the likelyhood of having to bump the major again.
A space for Bonfire maintainers and contributors to communicate
