4 ms·

The one thing that bothers me (which is not Caddy's fault at all) is the plugin system. If I understand correctly, I have to recompile Caddy for every plugin I

by embik 10y ago

The one thing that bothers me (which is not Caddy's fault at all) is the plugin system. If I understand correctly, I have to recompile Caddy for every plugin I want to use, right? Sounds like a limitation with Go which is really unfortunate.

kureikain 10y ago
Isn't that the same for Nginx? You still have to compile when you add new plugin? Caddy is very easy to use. You can download the build with what you want from their download page. The nicest thing about it is very simple config file, TLS out of the box, automatically renew as well.
- pilif 10y ago
  >Isn't that the same for Nginx? You still have to compile when you add new plugin? nope. That has been fixed with recent development versions that support loading plugins as shared libraries. For distros, that's very important because it allows them to ship much more configurable nginx packages as now plugins can be added as-needed.
- Nullabillity 10y ago
  I'm not a big fan of this either. Now you need to keep track separately of what your snowflake build enables, and when it's time to update, or if you want to add something else, then you need to go back and fill out the form manually again, and update manually. Also, it makes distro packaging dreadful, since you can either ship nothing and be useless for nearly everyone, or ship everything and surprise users if they switch to the official builds and find out stuff is missing. Nginx used to be as bad, but that's been fixed recently. Personally Caddy is also not very useful for me, since I use a reverse proxy, and Caddy didn't seem very helpful there the last time I tried. Oh, and it would have been nice to be able to make it generate self-signed certificates for staging environments.
  - cuu508 10y ago
    What problems did you have with reverse proxying? The article says 0.9 can now generate self-signed certificates like so tls self_signed
thwd 10y ago
Compiling a Go program is really quick and painless! Nothing like a similar C/C++ project.
- embik 10y ago
  I'm a Gentoo user myself so from a personal perspective I don't see any problem, but in a professional environment it's another thing I have to do - Install (and update) Go from somewhere because it's obviously not in the CentOS repositories (at least in an acceptable version), set up a build process and make sure to build updated versions, etc. Just dropping in libraries into some directory to be loaded as plugin would be arguably easier and is kinda "standard" for plugin systems.
  - fahrradflucht 10y ago
    I use Caddy on CentOS for quite a while. There is a Repo on Copr that let's you install it minimal or with plug-ins and it works just you would expect.
    - xena 10y ago
      Do you mean this copr[1]? I just pushed the 0.9 update. [1]: https://copr.fedorainfracloud.org/coprs/xena/caddy/ https://copr.fedorainfracloud.org/coprs/xena/caddy/
spriggan3 10y ago
Go does not allow dynamic library loading. So either your plugin system have to be backed by a third party language that has a interpreter/vm/whatever coded in Go, or you have to rely on some RPC method of some kind. So yeah it's a huge limitation with Go that makes it just unsuitable for a wide range of use cases.
- vetinari 10y ago
  Go does allow for consuming dynamically linked libraries, but it's not that simple as with C. For example, you have probably seen OpenGL bindings for Go - that's one of these things that would not work without dynamic linking. The issue is, that Go runtime has it's own ideas how the memory layout and stack layout should look like and these ideas are not compatible with __stdcall or __cdecl, so when calling C code, the runtime has to do a clean up. That used to involve a thread switch, now it involves a full register swap. What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps.
  - pjmlp 10y ago
    > What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Yes it does, since version 1.5, but the toolchain doesn't support it yet across all supported targets.
    - vetinari 10y ago
      Do you mean -buildmode=shared and -linkshared for linux/amd64? Don't you have to link the executable explicitly with the shared libraries? I.e. no dlopen()-like plugins?
      - pjmlp 10y ago
        Yeah something like that. Not sure how it exactly works, I just happen to still follow Go every once in a while. I see it as a good C replacement for many use cases that don't really need C as portable Assembler features. So from the gonuts discussions and design documents, I assume that at least on GNU/Linux systems it is already possible.
pjmlp 10y ago
It is not a Go limitation, rather a toolchain one. Dynamic linking support was introduced in version 1.5, but it only works in GNU/Linux currently. I expect it to eventually be available in all target OSes.

by embik 10y ago

kureikain 10y ago

Isn't that the same for Nginx? You still have to compile when you add new plugin? Caddy is very easy to use. You can download the build with what you want from their download page. The nicest thing about it is very simple config file, TLS out of the box, automatically renew as well.

pilif 10y ago
>Isn't that the same for Nginx? You still have to compile when you add new plugin? nope. That has been fixed with recent development versions that support loading plugins as shared libraries. For distros, that's very important because it allows them to ship much more configurable nginx packages as now plugins can be added as-needed.
Nullabillity 10y ago
I'm not a big fan of this either. Now you need to keep track separately of what your snowflake build enables, and when it's time to update, or if you want to add something else, then you need to go back and fill out the form manually again, and update manually. Also, it makes distro packaging dreadful, since you can either ship nothing and be useless for nearly everyone, or ship everything and surprise users if they switch to the official builds and find out stuff is missing. Nginx used to be as bad, but that's been fixed recently. Personally Caddy is also not very useful for me, since I use a reverse proxy, and Caddy didn't seem very helpful there the last time I tried. Oh, and it would have been nice to be able to make it generate self-signed certificates for staging environments.
- cuu508 10y ago
  What problems did you have with reverse proxying? The article says 0.9 can now generate self-signed certificates like so tls self_signed

thwd 10y ago

Compiling a Go program is really quick and painless! Nothing like a similar C/C++ project.

embik 10y ago
I'm a Gentoo user myself so from a personal perspective I don't see any problem, but in a professional environment it's another thing I have to do - Install (and update) Go from somewhere because it's obviously not in the CentOS repositories (at least in an acceptable version), set up a build process and make sure to build updated versions, etc. Just dropping in libraries into some directory to be loaded as plugin would be arguably easier and is kinda "standard" for plugin systems.
- fahrradflucht 10y ago
  I use Caddy on CentOS for quite a while. There is a Repo on Copr that let's you install it minimal or with plug-ins and it works just you would expect.
  - xena 10y ago
    Do you mean this copr[1]? I just pushed the 0.9 update. [1]: https://copr.fedorainfracloud.org/coprs/xena/caddy/ https://copr.fedorainfracloud.org/coprs/xena/caddy/

spriggan3 10y ago

Go does not allow dynamic library loading. So either your plugin system have to be backed by a third party language that has a interpreter/vm/whatever coded in Go, or you have to rely on some RPC method of some kind. So yeah it's a huge limitation with Go that makes it just unsuitable for a wide range of use cases.

vetinari 10y ago
Go does allow for consuming dynamically linked libraries, but it's not that simple as with C. For example, you have probably seen OpenGL bindings for Go - that's one of these things that would not work without dynamic linking. The issue is, that Go runtime has it's own ideas how the memory layout and stack layout should look like and these ideas are not compatible with __stdcall or __cdecl, so when calling C code, the runtime has to do a clean up. That used to involve a thread switch, now it involves a full register swap. What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps.
- pjmlp 10y ago
  > What Go does not allow, is putting Go code into dynamic library and then calling that from another go application - i.e. native go plugins for go apps. Yes it does, since version 1.5, but the toolchain doesn't support it yet across all supported targets.
  - vetinari 10y ago
    Do you mean -buildmode=shared and -linkshared for linux/amd64? Don't you have to link the executable explicitly with the shared libraries? I.e. no dlopen()-like plugins?
    - pjmlp 10y ago
      Yeah something like that. Not sure how it exactly works, I just happen to still follow Go every once in a while. I see it as a good C replacement for many use cases that don't really need C as portable Assembler features. So from the gonuts discussions and design documents, I assume that at least on GNU/Linux systems it is already possible.

pjmlp 10y ago

It is not a Go limitation, rather a toolchain one. Dynamic linking support was introduced in version 1.5, but it only works in GNU/Linux currently. I expect it to eventually be available in all target OSes.