Libelektra: visibility

[markus2330]

In applications with more than a dozen of configuration settings it is vital that users only see configuration settings which are relevant for them (and not see configuration settings only relevant to advanced users or developers).

I propose that we add following visibility levels:

• critical: setting must be changed, otherwise the system/application will fail
• important: setting has no reasonable default, must be set so that application can be useful
• user: often has reasonable default but most users would like to see it
• advanced: settings most users do not want to see, for example, related to resource usage or to enable experimental features
• developer: settings only relevant for developers of the application
• debug: settings for debugging an application
• disabled: settings which should not be seen by anyone, for example, which are always correctly derived or will be removed soon

Does someone know systems that already have such visibility levels?
There is:

• https://manpages.debian.org/jessie/debconf-doc/debconf.7.en.html#Priorities
• https://kodi.wiki/view/Settings#Settings_Level

[markus2330]

Please share your thoughts about this proposal. (e.g. @omnidan @reox @sanssecours @0003088)

[reox]

I think most applications solves this by using categories or multiple configuration files.
But I like the levels. For example in kodi, there are such settings. You can switch between Normal, Advanced and Expert and get a different set of settings displayed: https://kodi.wiki/view/Settings#Settings_Level

[markus2330]

Thank you for your input!

Yes, visibility levels cannot be used if users directly modify configuration files (unless you have some syntax highlighting or auto-completion). They are very useful, however, to generate config files (like debconf does), to show settings with a GUI/web-ui, or also to generate docu+manuals.

Thank you for mentioning Kodi, I added it in the inital post. I think both Kodi's and debconf's visibility levels can be mostly mapped to the proposed levels.

For debconf:

low -> advanced
medium -> user
high -> important
critical -> critical

For Kodi:

Basic -> important
Standard (Default) -> user
Advanced -> advanced
Expert -> developer (the intention is somewhat different, though)

Would it be useful to have an extra level between developer and advanced? Does Kodi really make a difference between "Advanced" and "Expert" level?

[reox]

I think the settings in expert are related to debug, developer and advanced. But the ordering is somewhat random... Sometimes you are required to set an option from the expert menu in order to have a "user" level experience (for example on old TVs there are some settings you almost always like to set, but they are in expert, iirc)

[markus2330]

Yes, it is known that user feedback loops are required to get such levels right in an application. Elektra won't be able to help there.

[markus2330]

The name "disabled" is problematic, maybe invisible, hidden, inactive, or derived?

For references:

• See also #1376 on thoughts about disabled keys.
• There is already a hiding feature with keys starting with "." (function: keyIsInactive, plugin: "hidden").

[markus2330]

instead of disabled internal, developer and debug redudant, instead of user "normal", or "default" or nothing?

[ingwinlu]

pythons log levels:
https://docs.python.org/2/library/logging.html#logging-levels
https://docs.python.org/2/howto/logging.html#when-to-use-logging

DEBUG | Detailed information, typically of interest only when diagnosing problems.
-- | --
INFO | Confirmation that things are working as expected.
WARNING | An indication that something unexpected happened, or indicative of some problem in the near future (e.g. ‘disk space low’). The software is still working as expected.
ERROR | Due to a more serious problem, the software has not been able to perform some function.
CRITICAL | A serious error, indicating that the program itself may be unable to continue running.

[markus2330]

Thank you, but I think log levels are not quite the same as visibility of configuration settings. Logs are by design not something for end users but configuration settings are for devs, operators, and end users. (Btw. our log levels are in src/include/kdblogger.h)

The new proposed visibility levels are:

• critical: setting must be changed, otherwise the system/application will fail. (e.g. boot device, hostname)
• important: setting has no reasonable default and most likely will fail, should be set so that application is (more) useful. (e.g. website URL to serve, relay host for mail relay)
• normal: often has reasonable default but most users would like to see it
• advanced: settings most users do not want to see, for example, related to resource usage or to enable experimental features or where defaults usually work
• developer: settings only relevant for developers of the application
• internal: settings which should not be seen by anyone, for example, which are always correctly derived or will be removed soon