luci-app-acme: render DNS API fields from the Structured Info

[stokito]

Maintainer: @tohojo

To show fields specific to a DNS API provider I made a list of all options and included them directly into the JS file.

The upcoming ACME.sh release all scripts now contain a Structured Info with list of options:

dns_alviy
Alviy.com
Site: Alviy.com
Docs: github.com/acmesh-official/acme.sh/wiki/dnsapi2#dns_alviy
Options:
 Alviy_token API token. Get it from the https://cloud.alviy.com/token
Issues: github.com/acmesh-official/acme.sh/issues/5115

So once release we can make an RPC call to gather the info for all providers right from scripts and render it.

The PR adds the parsing and rendering part. Once the acmesh will be updated in the OpenWrt we can include the script and RPC call.
For now I just generated it and included as a file (slightly stripped to keep disk space).

We might use the file converted to a JSON but the info is really big and it's takes much less space and ram to have a JS parser right on UI.

CC @hgl @systemcrash @dannil @IamRPDev

[tohojo]

Neat! Feels like the dnsapi.info.txt file should be part of the acme.sh package, not the luci app, though?

Also, AFAICT the parser is not terribly robust against malformed entries (judging from the unconditional shift() calls)? Not sure how the javascript runtime will handle failures, but IMO the parser should be smart enough to just skip malformed entries instead of aborting the whole thing (which is what I'm assuming will happen if the code throws an exception?).

[systemcrash]

Use JSON, whose handling is far more well-defined. But no, a more opaque format, so everything can be done in (ba)sh. Doesn't really matter where the file is, repo-wise, but if the GUI is the only thing that depends on it, here is its home.

[stokito]

The full parser with some tests is located here https://github.com/yurt-page/acmesh-parse-dnsapi-info

Right now we parsing own file that is 100% correct. Even now it will always parse to at least api Id and Name.

I'll try to check it later to improve error handling, maybe half of the parser can be replaced with a regexp :)

In the PR I added a stripped info version 16 Kb.
The full info version is 39 Kb and gzipped to 10 Kb.
Converted to JSON 115 Kb and gzipped to 12 Kb (see parsed.json).
The parser (dnsapi.js) is 3 KB but can be simplified to 1 Kb.

Maybe we can convert to JSON in shell but it's easier to do in JS, especially that we don't need for a full parsing (with Issues, Author fields).

[tohojo]

The full parser with some tests is located here https://github.com/yurt-page/acmesh-parse-dnsapi-info

Right now we parsing own file that is 100% correct. Even now it will always parse to at least api Id and Name.

I'll try to check it later to improve error handling, maybe half of the parser can be replaced with a regexp :)

The main thing I'm after from a robustness perspective is that a malformed entry will just be skipped, but not interfere with the parsing of the rest of the file. Should be pretty straight forward to add a test for that :)

In the PR I added a stripped info version 16 Kb. The full info version is 39 Kb and gzipped to 10 Kb. Converted to JSON 115 Kb and gzipped to 12 Kb (see parsed.json). The parser (dnsapi.js) is 3 KB but can be simplified to 1 Kb.

Maybe we can convert to JSON in shell but it's easier to do in JS, especially that we don't need for a full parsing (with Issues, Author fields).

I don't have a strong opinion about whether the file should generated as JSON at build time, or just be a concatenation of the definitions from the plugin files as you are doing now. But the "at build time" thing is important, IMO. I.e., the file should not be manually generated and included in the Luci package, it should be generated at build time of the acme-acmesh-dnsapi package and included in that package. Otherwise we have to manually keep the list of providers in sync between the two packages, and avoiding that is (presumably) the whole point of having an automatic parser in the first place :)

[stokito]

malformed entry will just be skipped

The parsing is lenient. It may potentially improved for a future when we switch to the parsing of extracted info directly from scripts. The acme.sh already made a release that contains the dnsinfo so actually we do can update the package and switch to extracting. There was some minor problems and I fixed and reviewed all of them so after the next acmesh release we can switch to extracting.

The PR can be merged today.

[tohojo]

The PR can be merged today.

Hmm, but why do it in this order? Seems to me that getting the extraction bits in place first, and the merging this afterwards makes more sense? :)

[stokito]

I'm not sure where the acmesh will be released and the current released version has some minor issues in the infos. But we can deliver one part today and the second later.