Cache the rules in a global variable in each script, as JSON,
and use JsonUtils directly to evaluate them. This will allow us to
close the WpConf in the future after loading the scripts.
Also change the order of the return values of the match_rules_apply_properties
function to be able to easily ignore the number of changed values,
which is useless in most cases.
This allows partially parsing a json object, allowing some parts to be
passed on as strings to another component that does its own parsing
(ex. a pipewire module)
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.
* Remove entirely the hook priority numbers and use before/after dependencies
* Split the WpEvent code out of WpEventDispatcher
* Add methods on WpEvent to interface with it from the WpEventDispatcher.
As a bonus, we can now also implement tooling to inspect which hooks would
in theory run for an event and write tests around that
* Removed some internal debugging facilities and log calls, will redo it later.
* Using spa_list now for the list of hooks, to reduce the number of allocations
happening in the "hook collection" algorithm
* Switched some internal data to use g_new0 instead of g_slice_new0
* Added g_free to free WpEvent structures... surprisingly, we were leaking them
before
The callback for the last test was getting called with non-string type and this
fails the test. fix it by sending string in correct format.
This test failure was not failing the "make test" this is known limitation in the test
setup. The limitation here is only with the last assert statement.
- WirePlumber Lua now facilitates Lua libraries/modules, utilize this and create
modules. Add some tests around this functionality.
- Create policy-hooks.lua containing all the hooks to find-target events
- Create policy-utils.lua module and push all the policy utility functions to it.
- Create common-utils.lua module and push the common utility functions to it.
- Remove all the above functionality from policy-node.lua and clean it up.
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.
- Add a new variable "name" in WpEventHook and use it to log all the
hooks(by name) picked up in _push_event(). This gives a clear picture
if hook is registered for a given event.
- Form a name for an event and a chain of events for an event run, log
both of them. This gives a clear picture of the events executed and
order in which they are dispatched.
- Similarly build hooks chain and print it in _source_dispatch(), this
gives a clear picture of the hooks picked and the order in which they
are dispatched.
- Log only the dispatchable(with hooks) events, this de-clutters
the log messages.
- 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.
Since the string length returned by wp_spa_pod_get_data() does not always match
the size of the actual json object because it is stored in contiguous memory, we
cannot always rely on that API to get the json string data.
The new wp_spa_pod_to_string() always allocates a new string with the same
length as the json size, guaranteeing that the string returned always represents
the json object, regardless of whether it is nested or not. It is always
recommented to use wp_spa_pod_to_string() unless you know what you are doing.
When an Array or Choice that contains Spa:Id appears as a value for an object
field, it is possible to retrieve the Id type from that object field type.
