We do not use these APIs, so there's no point in keeping them.
Realistically, every component that needs a section just does its
own parsing on it, so the _get_value() functions are not needed.
The fallback in _get_section() is also not needed, as we always
pass NULL and then test for it. In Lua, however, it seems we are
using the fallback to return an empty object, so that getting
a section does not expand to multiple lines of code. For that reason,
I have kept the syntax there and implemented it in the bindings layer.
Changes:
- Configuration files are no longer located by libpipewire,
which allows us to control the paths that are being looked up.
This is a requirement for installations where pipewire and
wireplumber are built using different prefixes, in which case
the configuration files of wireplumber end up being installed in
a place that libpipewire doesn't look into...
- The location of conf files is now again $prefix/share/wireplumber,
/etc/wireplumber and $XDG_CONFIG_HOME/wireplumber, instead of using
the pipewire directories. Also, since the previous commits, we now
also support $XDG_CONFIG_DIRS/wireplumber (typically /etc/xdg/wireplumber)
and $XDG_DATA_DIRS/wireplumber for system-wide configuration.
- Since libpipewire doesn't expose the parser, we now also do the
parsing of sections ourselves. This has the advantage that we can
optimize it a bit for our use case.
- The WpConf API has changed to not be a singleton and it is a
property of WpCore instead. The configuration is now expected
to be opened before the core is created, which allows the caller
to identify configuration errors in advance. By not being a singleton,
we can also reuse the WpConf API to open other SPA-JSON files.
- WpConf also now has a lazy loading mechanism. The configuration
files are mmap'ed and the various sections are located in advance,
but not parsed until they are actually requested. Also, the sections
are not copied in memory, unlike what happens in libpipewire. They
are only copied when merging is needed.
- WpCore now disables loading of a configuration file in pw_context,
if a WpConf is provided. This is to have complete control here.
The 'context.spa-libs' and 'context.modules' sections are still
loaded, but we load them in WpConf and pass them down to pw_context
for parsing. If a WpConf is not provided, pw_context is left to load
the default configuration file (client.conf normally).
This doesn't need to be a singleton, since we have the core registration
API available publicly nowadays. Makes things more clean for the API,
following the pattern of WpPlugin and WpSiFactory and simplifies the
built-in settings component in the internal component loader :)
This patch also moves nested configuration objects that are not considered
settings from the wireplumber.settings section to its own configuration
section (eg the rules array, the spa plugin properties, etc...). This allows
those objects to be merged with other same sections defined in other files.
They is really no needed with the new _get() API and the WpSpaJson API. In C,
users can use 'wp_spa_json_parse_{boolean|int|float|string}()' APIs to parse the
WpSpaJson. In Lua, users can just do 'Settings.get(setting, m):parse()'.
We need to use WpSpaJson to parse the values in WpSettings. This is because the
wireplumber configuration is written in JSON, so WpSettings should only hold
JSON values. To fix this, 2 API changes have been done:
- wp_settings_get_int() only accepts gint values, instead of gint64 values. This
is because the WpSpaJson API only parses int values, like spa_json_parse_int().
- wp_settings_get_string() now returns a newly allocated string, this is because
the string needs to be decoded in case it has quotes.
- Monitor to use the JSON APIs and move away from config/lua
- Enhance logic in wpsettings to parse settings which are JSON arrays,
some of the bluetooth properties are JSON arrays and parsing
logic confused them for a rule.
- Add corresponding tests around this logic as well.
- add integer and string version of the APIs,
- Also Refine the APIs, return value to indicate the setting existance
and a new param to return the value of the setting.
- add their lua bindings as well, in lua binding the return value nil
indicates that the setting is not defnied.
- Add corresponding C and lua tests as well.
- Add a few handy debug msgs.
- unlike pipewire, rules will be parsed during the bootup time, i.e
during the creation of the wpsettings object.
- The rules are parsed into the wpinterest objects and stored in the
wpsettings object, they will be eventually used to service the
apply_rule() API.
- Support pipewire syntax of rules defination in this version.
- settings.c tests conf file loading & parsing, metadata updates,
wpsetttings object creation and its API.
- settings.lua tests the API from lua scripts.
- Add a sample settings.conf file, this file contains sections copied
over from client.conf along with the settings section. Add a file
each for wp side and lua side of scripts.
- Make changes in base test infrastructure to take a custom conf file.
- Enhance the wp_settings_get_instance_api() to be take metadata_name
parameter. So, Wpsetttings is now a singleton instance for a given
metadata file.
- Enhance the m-settings module also to be take metadata_name parameter.
this is handy for lua side of tests as its cumbersome to do this is
lua.
