With the availability of plugins it becomes more important to configure individual participants, as plugins can easily result in converter ambiguities. The following was the solution discussed today:
- Give names to participants (client have to do this when creating participants) to identify them in the configuration mechanism
- Names will be logical names
- Are names always required? -> Otherwise it might be impossible to configure some participants if the programmer forgot to give names to them
- Do names need to be unique (at least within each process) or are they treated like tags?
- If they are not unique, it might be that the developer chose a grouping of participants with a single tag, which turns out to be an over-generalization and recompiling will be necessary to disambiguate them
- If the are unique, composing multiple RSB libraries in a single binary might lead to name clashes. Some kind of scoping will be necessary.
- Add participant-wise configuration options based on separate files
- A new section will be added to the options, where each key corresponds to the aforementioned participant names/tag and the values dispatch to separate configuration files using the usual configuration syntax. Like this, each named participant can be equipped with additional configuration options which override the defaults. The additional files are so far called "profiles"
- If a named participant is not included in the
rsb.conf, it will use the process-wide defaults.
- If filenames are just a basename, the usual cascade for finding config files will be used, absolute files are also supported
- Add an info tool which explains which configuration property is caused by which source to make it easier to debug configuration errors (see #1458).
Like this, extension packages like for the iCub can install profiles in the system and the user only has to dispatch to them in the config.