Support arrays as values in JSON configuration source

[ChengTian]

Need to figure out a proper representation of arrays when they used as values. Also need to figure out the corresponding things in xml and ini files.

[tillig]

Any update on this? It seems like a minimum requirement for all but the very simplest configuration. I'd like to know if I can count on it being in the release or if I'm going to have to roll my own config system.

[sslava]

For now config values are stored in Dictionary<string, string>. If we could change it to Dictionary<string, object> it could simplify support of custom data type deserialization. At least for .json config files. And use generic T Get<T>() for values retrieval, as @Kieranties mentioned in #130.

[glennc]

@victorhurdugaci Assigning this to you so that getting a design together for it doesn't fall through the cracks.

[sslava]

Hi folks! Any progress on this? :)

[glennc]

Can you guys drop me some examples of what you want to write in the config files to help drive this? Examples of the types of configuration, simple and complex ideally.

[tillig]

My primary use case right now is Autofac configuration. In that, you can configure different components and modules to be registered with Autofac. For example, I might imagine something like this:

{
  "components": [
    {
      "type": "Some.ConcreteType",
      "services": [
        "First.Exposed.IInterface",
        "Second.Exposed.IInterface"
      ],
      "parameters": {
        "simpleParam": "SimpleValue",
        "listParam": [1, 2, 3],
        "dictParam": {
          "name": "value"
        }
      }
    },
    {
      "type": "Some.ConcreteType",
      "services": ["Different.IInterface"]
    }
  ],
  "modules": [
    "First.ModuleType",
    "Second.ModuleType",
    "Third.ModuleType"
  ]
}

The interesting bits in that example from an ordinal list perspective:

• A concrete type can expose 0 or more services.
• You can expose the same concrete type under different interfaces using different configurations. Notice in this case we expose the same type, but the first setup has some parameters that configure the registration; and the second setup doesn't have those parameters and exposes it as a different interface.
• Parameter values for a component registration may be scalar, list, or dictionary values. Via XML we've previously been able to accommodate for all three scenarios.
• Modules (programmatic configuration bundles) are just a list of types that need to be treated like modules. There's no key/value nature to them, it's just a list of type names.