Configuration interface for packages

[j005u]

The UI could offer extended configuration options for packages that have them.

We know already @bri3d needs a way to select the font for msp-osd and @funnel needs a way to switch between PAL/NTSC.

On the other hand we can also expect there to eventually be an interface on the Goggles themselves for this, so I think this needs quite a bit of thought put into it how to actually handle it.

[stylesuxx]

We discussed a couple of options:

• setting properties - downside, they are not persistent
• json file with some pre defined widgets (select, range, text, number)
• extending the currently available interface on the goggles - XML?

[Alia5]

My vote would be option 2.
Additionally, I think there should be a command configurable that runs on file-change/save
Packages that spawn a daemon can always resort to inotify 😇

[j005u]

Got any proposals for a schema?

Bonus points if there's already tooling around for manipulating it.

My two cents would be could we also support YAML please?

[stylesuxx]

Before diving into this, I think we should make up our minds how we want to interface with the settings. Will it only be for the web configurator or do we also want the UI on the goggles to use the same infrastructure.

Regarding format, I think we should decide for one format, I have no hard feelings for either JSON or YAML, I just don't see the need for supporting multiple formats - at least not from the get go.

I suggest the following widget to start with:

• Checkbox: Simple wrapper for boolean options
• Select: Key, Value pair - unlimited amount of options, only one can be selected
• Text input: Input for text, with validator options for used charset and length
• Number input: Slider element with min, max and step size

A settings component would consist of two files, one schema where it is defined which values there are available and one file where the settings are saved to, this should be a simple key/value store.

The schema file could also consist of services that need to be restarted once settings have been changed. This could look like so (Example as JSON, but could be anything):

{
  "settings": {
    "key_checkbox": {
      "widget": "checkbox"
    },
    "key_select": {
      "widget": "select",
      "options": [
        {
          "key": "key_1",
          "value": "value_1"
        },
        {
          "key": "key_2",
          "value": "value_2"
        }
      ]
    },
    "key_range": {
      "widget": "range",
      "min": 0,
      "max": 10,
      "step": 1
    },
    "key_text": {
      "widget": "text",
      "allowed": "abcdefghij",
      "minLength": 0,
      "maxLength": 10
    },
  },
  "services": [
    "service_1",
    "service_2",
  ]
}

settings file:

{
  "key_checkbox": true,
  "key_select": "key_2",
  "key_range": 2,
  "key_text": "abc"
}

[j005u]

Structural:

• Should each option have a short label, as well as a long description (can be shown eg. on hover)?
• Should options be groupable under a title?

Types (definitely "stretch goals"):

• Files (doom.wad, background images, font files)
  Config should list target upload folder or specific path?
• Bonus points for special image type with preview

Services should really be units. Script type units should be started rather than restarted. Eg. one can define a config to upload screensaver images and the unit started is a script that converts them to the framebuffer formats and copies them in place.

Where should we ask packages to store the definition and the config?

Regarding JSON vs YAML: they're interoperable and there's easy tooling to convert between the two. If we must have one, then I prefer YAML for the far superior manual authoring experience. But that's just my personal preference, happy to go with whatever the group decision comes to.

@bri3d @funneld ping.

[j005u]

Having given it another thought in relation to linking to package READMEs, here's my thinking:

How about we define a package.yaml schema that includes control metadata, extended metadata (README URL), the dinit unit(s) and configuration definition for the configurator.

This package.yaml can be used both by a supplied Makefile that uses it to generate the control file for ipk purposes as well as the yaml itself being included in the control directory so that it can be picked up by the configurator from the installed packages index?

Please tell me if I've been writing too many Helm charts lately and have gone mad.

[stylesuxx]

• Should each option have a short label, as well as a long description (can be shown eg. on hover)?
• Should options be groupable under a title?

We can do that, how do we solve the multi lingo issue here? Makes no sense to do this via app translation interface, so each package would need to provide it's own translation files then.

Types (definitely "stretch goals"):

• Files (doom.wad, background images, font files)
  Config should list target upload folder or specific path?
• Bonus points for special image type with preview

Yeah, we can add arbitrary types later on, I would like to start with a set of bare minimum and go from there.

Services should really be units. Script type units should be started rather than restarted. Eg. one can define a config to upload screensaver images and the unit started is a script that converts them to the framebuffer formats and copies them in place.

I am not entirely sure which implications this would have on the configuration interface?

Where should we ask packages to store the definition and the config?

How about:

• /etc/pkg-settings/$PKG_NAME/definition.yaml
• /etc/pkg-settings/$PKG_NAME/config.yaml

Regarding JSON vs YAML: they're interoperable and there's easy tooling to convert between the two. If we must have one, then I prefer YAML for the far superior manual authoring experience. But that's just my personal preference, happy to go with whatever the group decision comes to.

OK, let's go with YAML - we can add JSON later once we have a solid MVP.

How about we define a package.yaml schema that includes control metadata, extended metadata (README URL), the dinit unit(s) and configuration definition for the configurator.

This package.yaml can be used both by a supplied Makefile that uses it to generate the control file for ipk purposes as well as the yaml itself being included in the control directory so that it can be picked up by the configurator from the installed packages index?

Yeah, that's fine with me.

[j005u]

Noting a few things during the CLI implementation:

• text allowed changed to text pattern and treating as regexp
• servies changed to units (because they are dinit units)
• using /opt/etc/pkg-settings/ rather than /etc/pkg-settings/
• added name property for each setting because value in select implies textual options - unless it's multi select?
• json because jq and also because easier library access in general

Re multi lingo: I think we can support it, but we can't demand it, because the configurator might get an arbitary number of languages. Same with readme's etc.

[j005u]

wtfos-package-configuration is mostly done, but a few thoughts came up during implementation:

• Should the "widget" be "type" instead with bool, int, string enum as options?
  • They would retain all the same properties as now, but the UI can decide which "widget" it wants to draw based on the constraints?
  • Could always include additional metadata for a proper GUI
• Reffering to Download package diagnostics #106, we are getting into a situation where we need to store more metadata for the packages.
  • Should schema.json be just about settings or should we rename it and have it be our "package.json" (probably not a great idea to use the same name as node)
  • Also at some point we get into an overlap with opkg metadata.

We could also say that wtfos-package-config needs to know about the things right now in schema.json and any other metadata is a separate concern. Looking for feedback.

[j005u]

https://github.com/fpv-wtf/wtfos-package-config

Version 0.1.0 (not in repo) ipk published.

Would appreciate a review.

Also I didn't apply any of the changes proposed in the previous post yet.

[stylesuxx]

To summarize this a little bit:

• We have the "backend" solution of actually applying those settings via wtfos-package-config (makes no sense to use this since all we need to do is save a resulting JSON file)
• We agreed on using the JOSN schema react component as a starting point for "generic" settings
• We will add custom widgets like for example for the font selection
• Packages should have a detail view, where settings should be shown: /packages/$PACKAGE_NAME

TODOs:

• Route for package details (Display name, description link to readme. Allow installation and removal. Display settings only if installed.)
• ADB wrapper function to fetch a packages settings JSON
• ADB wrapper function to save resulting settings JSON
• Render Form via JSON schema react component

[j005u]

Note: I'd like to get rid of wtfos-package-config altogether. There is not point in attempting to port the validation rules over, as react-jsonschema-form should do the validating by itself. And at that point wtfos-package-config wouldn't do anything except save to a file.

We can use the same paths, i.e. /opt/etc/package-config/$package-name/config.json for the output though. And store the schema and json in the same folder.

[stylesuxx]

Configuration interface on package detail page is now implemented via react-jsonschema-form.