caddyserver
Adapters are counted as standard modules
Because we use a bit of a hack to make config adapters count as modules, these plugins are incorrectly counted as "standard" (i.e. bundled into the core distribution from this repo).
Since config adapters aren't actually config modules, we should probably not count them as such.
And maybe list-modules should be list-plugins.
I dunno. Thoughts?
(Thanks to @Mohammed90 for discovering.)
@mohammed90 I'm now reconsidering this. I don't think we should count them as normal config modules (because they are not). Maybe we should rip out the linked code (if possible, if you agree).
Instead, let's reveal which adapters are installed by setting the Accept header in our admin API's /load endpoint.
@mohammed90 I'm now reconsidering this. I don't think we should count them as normal config modules (because they are not). Maybe we should rip out the linked code (if possible, if you agree).
Instead, let's reveal which adapters are installed by setting the Accept header in our admin API's
/loadendpoint.
I'm not sure I follow. Do you mean it'll be in the response Accept header when the user calls the endpoint with either GET or HEAD? For reference, we added that code because it wasn't possible to know which adapters are in the build without it.
@mohammed90
Do you mean it'll be in the response Accept header when the user calls the endpoint with either GET or HEAD?
Yep. HEAD probably. That way you can get the Accept header before POSTing. Or, honestly this might be easier: just POST with your Content-Type that you want to use, and if it fails, you'll get an Accept header back that tells you what is accepted.
POST with your Content-Type that you want to use
Not sure if you remember, but you implemented support for Content-Type: text/<adapter-name>. I like the HEAD idea. I still think we should have something in the CLI. Should we add a command list-adapters? We probably also should list the adapters in the help text of the --adapter flag and the adapt command,
Not sure if you remember, but you implemented support for Content-Type: text/
.
Yeah, but that doesn't tell you what adapters are available. I just am suggesting that if you want to know if your preferred adapter is supported, you can try POSTing with it to begin with, instead of always doing a HEAD first.
What if we put the list of adapters in build-info?
if your preferred adapter is supported, you can try POSTing with it to begin with, instead of always doing a HEAD first.
That feels wrong. The HEAD idea is very cool. I don't know what I feel about build-info. It doesn't seem like the right place.
That feels wrong. The HEAD idea is very cool.
I'm suggesting both should be possible. If your adapter is already installed, then you don't need an extra HEAD request before. Just do the POST. But if the POST fails, you get the Accept header anyway (you don't need HEAD).
HEAD would still be useful if you want to get information only, and you don't (yet) have a config to load.
I don't know what I feel about build-info. It doesn't seem like the right place.
Hmm. I'm just trying to keep the CLI simple. Why does build-info feel like the wrong place? It should print information about the build. In fact, I think it technically already shows you what packages are compiled in, it just doesn't list why they're compiled in.