Each component can optionally "provide" a feature, which is basically
a string that describes the feature (ex. "support.dbus"). If the
component loads successfully, the feature is marked as provided and
can be tested for its presence with wp_core_test_feature()
Now that we have proper module load order, we can have this shared
dbus connection in a module instead of the library. The module has
to be loaded before any other modules that need it, obviously.
There is no reason to return the component object... all components
are supposed to be long-lived objects that are referenced by the
registry and there is API to find them. The caller is only interested
in the success or failure of the operation.
Regarding the core parameter, the case used to be that WpComponentLoader
was a WpPlugin, so it had a reference to the core internally, but since
this is no longer a requirement, we need to pass this explicitly
This change completely refactors the way components are loaded in wireplumber:
- The module_init() function must return a GObject now. This object is either
a WpPlugin or a WpSiFactory in the current modules.
- When the component loader initializes a module, it automatically registers
the WpPlugin or WpSiFactory with their respective methods. There is no need
to register the WpPlugin or WpSiFactory in the module now.
- The wp_core_load_component() API has been refactored to be asynchronows. This
allows the component loader to automatically activate WpPlugin objects, and
therefore allows the application to directly get the WpPlugin without having
to find it. This simplifies a lot of things.
- The 'ifexists' and 'nofail' component flags now work even if the respective
WpPlugin could not be activated.
- The code that loads components in main.c has also been simplified a lot,
and the option to load dangling components has also been removed.
The component loader is a more generic and extensible mechanism
of loading components; modules are one type of component...
The idea is to make scripts and config files also be components,
loaded by plugins that inherit WpComponentLoader
* use the activate/deactivate system from WpObject,
which allows async activation and error reporting
* drop 'module' property, use 'core' from WpObject
This one offers API to interract on a lower level with
the D-Bus reservation API and uses GDBus high level bindings only.
Also, this one implements the full Acquire procedure, calling
RequestRelease() on the peer and requesting the name again with
REPLACE_EXISTING
