Create a flexible way to handle server/gui parameter configuration

[adlarkin]

Desired behavior

It was brought up in #1163 (comment) that there may be "small" options/parameters for server/gui configuration. It would be nice to have a way to configure these parameters that doesn't require modifying the xml config files directly. This would allow for easy modification of parameters that may need to be tweaked frequently, and would also make it easier to find specific parameters. Perhaps we can do something similar to ROS, where yaml files can specify a list of parameters that are then passed to a larger config file such as roslaunch (more info about the ROS yaml file concept can be found here).

Another benefit from adding this functionality is that we could remove some hardcoded values in the source code (here's one example).

Alternatives considered

Place all parameters in the server/gui xml config file. While this works, this could result in bloated configuration files that make it hard to find particular parameters for tweaking.

These parameters can also be configured from the command line, but this would probably be overkill regarding the implementation work required vs the resulting added functionality.

Implementation suggestion

TBD

Additional context

#1163 (comment)

[chapulina]

+1 to have a way to configure more of these parameters

Perhaps we can do something similar to ROS, where yaml files can specify a list of parameters

I'm not sure what would be the advantage here though, is it simply a difference between XML and YAML? Since we already support XML configs, I worry that adding yet-another-configuration-file (YACF? 😄 ) may add unnecessary complexity.

[adlarkin]

My thought is that perhaps the xml config file does things like define plugins used, and a separate "parameter file" may be used for either configuring things that aren't plugin specific, or for coming up with different "plugin configurations". Then, this parameter file can be "injected" into the xml config file to result in a plugin configuration that has a set of plugin-specific (and perhaps non-plugin specific) parameters.

For example, maybe users use a handful of plugins almost all the time, but these plugins have parameters that they want to configure differently for different use cases. Instead of having several xml config files that have a lot of repeated plugin boilerplate code, they can have one xml config file with the plugin boilerplate code and then several parameter files that specify how the plugins are configured. Then, all users would have to do is change which parameter file is imported in the xml config file.

Does that make sense? I'm not sure if this approach would make parameter customization easier or harder (I think it would be useful to come up with some concrete examples of things that we may want to "parameterize"). We could also just have all parameter customization done in the xml config files, if those files don't get too large/complicated. I'm open to ideas!

[adlarkin]

@chapulina following up on this, I'm wondering if this is really an "issue". Currently, we can expose parameters through SDF and XML config files, and users can change things there, right? Is that not flexible enough? Being able to modify the SDF/XML config file seems like a reasonable solution since this doesn't require re-building code in order to test parameter changes. Perhaps we can close this issue? I worry that we are trying to over-engineer parameter configuration here.

[chapulina]

Yeah I'm ok keeping it simple and having one way of expressing parameters 👍

I do think we need more ways of combining and parametrizing our current config files though.

[adlarkin]

I do think we need more ways of combining and parametrizing our current config files though.

I'm not sure if I follow/understand completely. Are you referring to the gui.config and server.config files that are stored in ~/.ignition/gazebo/<version_number> by default? If so, can you elaborate a little more on what's lacking with the current approach?

[chapulina]

I need to take some time to write a proper issue for this. Some things I can think of now:

• Support appending plugins from config and SDF, see Config file loading options #1012
• Support loading multiple configs at once, or one config extending the other, so that a few smaller configs can be reused without duplication
• Passing parameters to configs at runtime

[adlarkin]

Thanks, that makes more sense now 👍 should we close this issue then, since you're going to create a different issue for the items you mentioned above?

[chapulina]

SGTM, thanks!