Should config return a string rather than a Vec?

[thomastaylor312]

I was doing some thinking and I wanted to bring up a possible idea: What if config values were all strings? My main reasoning around this was thinking about "what is the 80% use case?" Most of the time, configuration values are strings of some sort, with some exceptions for things like keys or certificate data. You can also see examples of this in things like Kubernetes or Nomad, where their configuration expects strings and then people use base64 to encode data.

This API might be easier to deal with rather than forcing what I think is the more common use case to constantly have to parse a vec of bytes into a string. Curious what other people think here

[kate-goldenring]

I agree that string is likely the 80% use case -- might make sense to choose this more user friendly API until we get a counter example.

[thomastaylor312]

@Mossaka any comments here before I open a PR?

[Mossaka]

I am not familiar with most runtime config APIs though but I agree if this makes implementation much easier.

[endocrimes]

+1 from me (as a former-or-current maintainer of both of the mentioned orchestration tools 😅) - there's practically nothing that can't be reasonably encoded as a string, and the minor annoyance at sometimes needing to parse a value from a string is often better defined than operating on arbitrary bytes.

[jcchavezs]

I just stumbled upon this ticket by chance and respectfully I am very impressed on how things are taken for granted. In such a proposal like this I would expect to see references to existing implementation and or runtimes and a stronger argument on what is the impact of "parse a vec of bytes into a string" because if this is a UX concern a helper function that does this could be enough. Also, the choice of "80%" could be misleading if not backed by data or heterogeneus examples, what if that 80% is actually a 40%? why should future contributors trust this number?

I am not against this (I don't know enough to be against or in favour) but the reason for this discussions to be held in a public issue is transparency and data+sources is fundamental for transparency otherwise it looks like a few folks agreed on something based on information and use cases that is only on their brains.

[thomastaylor312]

@jcchavezs Thanks for the feedback here! I don't know if we can actually get super hard numbers here, but what I was referring to was how other types of runtimes do this as well as the ergonomics involved. In some senses it has to be a best guess for now and then we find out during initial implementation if it works or not for people. I opened this after implementing inside of wasmCloud and finding the ergonomics less than desirable. Let me address each of these concerns separately:

Platforms and how they do config

• Kubernetes: Both ConfigMap and Secret expect a map[string]string. The standard practice is that binary data needs to be encoded with base64 (whether it is in config maps or secrets) or it should be loaded into a file
• Nomad: Doesn't have config built in its core, but env vars are map[string]string. For secrets, it uses Vault and loads things in either via file or templating
• Environment variables: For all intents and purposes, these are strings. Yes, I know they can be bytes, but when you look at their usage and many APIs across higher level languages, strings seem to be the most common. There has been effort in the POSIX spec to support bytes, but many high level languages like Java, Go, Rust, or Python either only have support for strings or have a more complex API if you need to read raw bytes (this is why Rust's OsString type exists)
• wasmCloud: We store our config with map[string]string to make the API easier to use
• Spin: Hasn't implemented a config directly yet, but their variables interface uses string keys and values
• Various CI/CD pipeline variables and secrets: Almost all strings
• AWS Lambda, Cloudflare workers: Lambda appears to use strings and Cloudflare workers use strings or JSON

Basically, when I look around, I am pretty sure (but please provider major counterexamples if you have them!) most things use strings by default

Ergonomics

You are correct that you could use a helper to parse the string, and most of those already exist in various languages! However, if the majority of platforms use string as a default it is an extra step (probably doesn't impact performance too much, but I haven't tried) and, more importantly an error that has to be handled. This is actually the exact reason Rust hides this behind the OsString type, as that has helper methods to convert to a real string, but the "default" function of var returns a String. If strings are as common as they appear to be, I'd prefer that those with advanced use cases (who probably have plenty of experience in the technology) be the ones to swallow the pain of extra error handling. Also, I'd like to note that if we move to using just strings, that doesn't mean we can't add raw bytes in the future if there is a need! We just want something that works well here at the beginning, especially for those first implementing it

Hopefully that helps provide some more information around why I opened this in the first place