Most of the configuration settings have a default value when they are loaded by
the Lua scripts if they are not present, so we leave them commented in the
configuration. This will make the configuration smaller when supporting layered
configuration, as all the commented sections will be part of the override files.
We cannot guarantee that the object's bound-id is always valid when an event is
triggered, especially when an object is removed. This patch uses the new object
wireplumber unique ID to index Lua tables, fixing runtime WP_PROXY_FEATURE_BOUND
check warnings.
- 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.
- remove scheduling rescan via core APIs instead use the event stack for proper
scheduling.
- The rescan & handlelinkable hooks will push new findTargetSiAndLink events one
per session item.
- Register a new "after-events-with-event" hook for findTargetSiAndLink event,
it runs with lower priority than the rescan hook and so rescan hook can cancel
unneeded findTargetSiAndLink events.
- Register hooks for move and follow properties.
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()'.
This scheme provides for an orderly execution of hooks as the priorities
are controlled from one single place. Enumeration is defined in such a
way that new items can be added easily.
All the event hooks are changed to get the priorities from this
enumeration.
- 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.
