> However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime.
Actually there is.
Go plugins are something we're looking at, but it's complicated and the technology is currently immature. Please read this forum thread in full: https://forum.caddyserver.com/t/go-1-8-plugin-model/934?u=ma...
Like the rest of Caddy, I find the plug-in system to be simple and solid. Some people just seem to like complexity. (smile)
Is there any way to query what plug-ins are bound into a Caddy exe? (given that I'm a non-Go-programming, Windows guy)
An idea I had for the website was to allow us to sign in and have accounts. Downloads and plug-in preferences could be tracked. (It might even lead to a way to pry some money out of cheapskates like me with premium plug-ins and whatnot.)
> Is there any way to query what plug-ins are bound into a Caddy exe?
Run `caddy -plugins`.
The new Caddy website -- coming out hopefully later this month -- will allow developers to create accounts and release their plugins themselves, without me having to do it manually. I have given some thought to allow anyone to create an account but I need to work out some details for monetization first, if that's the route it takes. Thank you!
It sound like a neat project where there are some good defaults and where most weaknesses (performance, flexibility, etc) come from golang. It would be interesting to see a rewrite in another language.
Anyway, it is still a problem if you encounter a bug in any dependencie: you have to recompile every application using it.
I'm confused, aren't Go plugins exactly the feature you want? And on that note, it was just introduced as of 1.8, wasn't it?
Seems a bit harsh to criticize a project for not using (during it's development time) unfinished and not production ready features.
Having to recompile to add functionality that alternatives provide as dynamically loaded plugins is insane. This is 2017. Linux has had loadable kernel modules since 1995, and I worked on them for other versions of UNIX as far back as 1991. I understand that it's hard for a Go program to support plugins written in other languages using a more conventional runtime. No problem there. However, there's just no excuse for relying on recompilation instead of dynamically loading modules also written in Go and thus using the same runtime. I really want to like Go, but as long as the Go community clings to long-discredited ideas regarding things like packaging and distribution and symbol versioning I just don't feel like I can depend on it to build infrastructure that will remain robust over time.