Specify config to never change during the lifetime of the component.

[badeend]

Currently, the spec does not specify whether config values are allowed to change during the lifetime of the component.
I'd suggest: No. 🙂 Because: simpler semantics & API design.

This is in line with wasi-cli's environment variables: https://github.com/WebAssembly/wasi-cli/blob/main/wit/environment.wit

In my personal experience, it typically doesn't make much sense to do it any other way.

• For short-lived (e.g. instance-per-request) components there's practically no difference between having them be static or not.
• For long running applications, by far the simplest and most common way of handling config changes is simply restarting the entire application. Even high-availability software such as nginx don't bother with hot reloading.

[thomastaylor312]

This is an interesting discussion for sure! So I completely agree that for short lived components, this is a good rule to have. For longer running ones, many of the people we discussed this with initially actually really liked the possibility of the config hot reloading. It is difficult because there are shades here. There might be some top level config (or secrets) that you set once at the beginning of the process (like TLS certs or the like), but something like an upstream URL or redirect would be totally fine/easy to pull from config and use that instead in a dynamically updated way. For context, wasmCloud implemented it to be dynamically updated, but we can change that depending on consensus

Curious what @devigned has to say here as well

[badeend]

many of the people we discussed this with initially actually really liked the possibility of the config hot reloading

For extra context, are you able to share some of these use-cases?

[badeend]

Aside: For proper hot reloading support, wouldn't there also need to be some kind of mechanism to get notified of config changes?

Maybe, an interface like this would be more fitting to explicitly model the "changes over time" aspect?

interface store {
  type config-map = list<tuple<string, string>>;

  initial: func() -> config-map; // The config values at startup. Never changes. Effectively a "value import" which the component-model doesn't support (yet).
  current: func() -> stream<config-map>; // Get a stream that is automatically updated with the latest config values.
}

[thomastaylor312]

For extra context, are you able to share some of these use-cases?

I think the majority of cases were people who were coming from Kubernetes and having been bitten and/or annoyed by needing to find a way to watch a config map to get new config values to a running application. The thinking here is that if business logic is always calling config.get("key_name") each time the logic was called. In this case, there is no need for an update, just that the business logic looks up the value.

However, I do think the interface you described might be good to have for longer lived things. Maybe the best solution for now is to do like you first described and say "config doesn't change during the lifetime of the component" and then as we get more long-lived components we can add an additional interface that looks like something along the lines of what you described above