The proxy API is the one that we would like to expose for applications
and the other API is used internally when implementing modules or
factories.
The current pw_core object is really a context for all objects so
name it that way. It also makes it possible to rename pw_core_proxy
to pw_proxy later.
The pw_remote object is really a wrapper around the pw_core_proxy.
The events it emits are also available in the core proxy and are
generally awkward to use.
With some clever new pw_core_proxy_* methods and a pw_core_connect
to create the core_proxy, we can convert all code away from pw_remote.
This is a first step in this conversion, using the pw_remote behind
the scenes. It leaks into some places because it really needs to become
its own struct in a next step.
Let the core load a set of default modules.
Add a key to control what default set to load, falling back to a
reasonable set. Make the daemon not load any set and rely on the
config script to load modules.
Remove the parent_id from the global event. Remove the parent
and owner from the global object.
Use properties instead to mark parents and owners of objects.
Properties are easier to control for client exported objects and
usually a simple parent/child is not enough. For example, a client
exported node has the client as a parent but also the factory that
created the node.
Pass a factory_name in the object_info of monitor and device.
Restructure the factory name to mean something functionaly. With
the factory to library mapping this then means that the implementation
of certain factories can be configured in the config file.
