WebBackend API: List available settings

[maul-esel]

In discussions with @Heizmann and @bahnwaerter, we noted it might be useful if there was a backend API to list available (i.e., existing and whitelisted) settings (see comment here).

Benefits

• Clients do not have to know and duplicate all the information about existing settings, including things like the available choices.
• This reduces the chance that this data becomes out-of-sync.
• Different clients can choose if they show only a small selection of settings (e.g. our web interface) or more.

Details

• Should the API return all settings for all known plugins, or does the client provide a toolchain?
• ... ?

[danieldietsch]

I don't see any benefit in providing such an API route and I would advise against it.

• There should not be a difference between existing and whitelisted settings. A client can only access whitelisted settings, that is the whole point. This could change if we add authorisation to the backend, but I don't see that as feasible in the near future (in particular, as we then would have to deal with security).
• Enumerating available options makes sense if you want to have a client that exposes all available options to its users. Our web interface doesn't do this: it uses settings per tool and some of them are exposed (as defined in the webinterface). Converting .epf to web interface config is automatic (using the CLI options in Ultimate). This also provides the available choices.
• For our webinterface, the best way to prevent out-of-sync settings would be to validate the settings at deploy time, e.g. by providing function in UltimateCLI or the WebBackend that takes a client config in our DTO format and checks whether these settings actually exist. Due to the modular structure of Ultimate, this still might fail if UltimateCLI or the WebBackend does not have all plugins.

EDIT: There are use-cases that benefit from such an extension, e.g., a web version of the DEBUG GUI. It would still require whitelisting due to security concerns, but it might be helpful. My current impression was that no one wants that and all clients restrict the options that they show to their users.

[maul-esel]

Just to clarify: By "existing and whitelisted" I mean the intersection; the API client should not be able to distinguish them (it should not be able to see non-whitelisted settings).

[maul-esel]

@schuessf and I discussed a related option: To prevent out-of-sync settings, should we automatically generate the web interface's config.js from an .epf file (e.g. SV-COMP settings) as part of the website build process?

[danieldietsch]

Yes we should, and its rather easy. Its a combination of a template, various calls to UltimateCLI, and some jq magic.

EDIT: Although, we should do that as part of the deploy process, not as part of the build process.

[maul-esel]

We do now generate the web interfaces settings file from EPF (see here), thus making sure they are in-sync. Since there was no further interest in (and some opposition to) an API route to list settings, I am closing this issue.