The Doxygen "Modules" page is not very illuminative, as different parts
of the API are mixed together and not all parts are included.
Try to address this:
Put all parts of the public API to some Doxygen group, usually one group
per header file. Use short, systematic names.
Make these groups sub-groups of a few top-level groups, roughly
corresponding to the different logical parts of the API (core, impl,
stream, filter, spa, utilities).
Subdirectories buffer, control, debug, monitor, pod, support and utils, others
are still missing. Headers are grouped either per subdirectory (e.g. buffer/
gets added to group spa_buffer) or per-file (e.g. spa_json is a separate
group), whatever seemed like the most sensible approach.
Use a different way to generate the upper bits of the ASYNC mask
instead of undefined shift as warned by sanitizer
Add some unit test for this
See #497
Make struct spa_node_events for events emited from the main thread
and keep the spa_node_callbacks for the data thread callbacks.
The add_listener method installs the events and it's possible to
install multiple handles. Adding a listener first emits the info
and port_info events when installed, similar to how the PipeWire
proxy bind works.
This removes the need for the spa_pending_queue and makes it easier
to implement the _sync versions.
Add some helpers to make it easier for plugins to emit all the info
to new listeners.
Use the listeners for devices as well.
Let the caller remove the pending result when finished.
Use non _sync verions to enum_params in node/port/device.
Set result.id in alsa and v4l2 correctly.
Don't use special callback in node to receive the results. Instead,
use a generic result callback to receive the result. This makes things
a bit more symetric and generic again because then you can choose how
to match the result to the request and you have a generic way to handle
both the sync and async case. We can then also remove the wait method.
This also makes the remote interface and spa interface to objects very
similar.
Make a helper object to receive and dispatch results. Use this in the
helper for enum_params.
Make device use the same result callbacks.
Make a special function for pending results to make it clear that it
is different from normal results. Don't pass result code to result
function, it is not useful because since the callback is called, all
must be fine.
The spa_pending is removed from the list right before the callback
and can thus be freed in the callback. Pass the spa_pending in
the pending callback so that extra data can be added that way.
Reuse spa_pending objects in link and nodes instead of allocating. We
always only have one pending operation and we can cancel any pending
previous operation by removing the pending.
Remove the done and error callbacks. The error callback is in an
error message. The done callback is replace with spa_pending.
Make enum_params take a callback and data for the results. This allows
us to push the results one after another to the app and avoids ownership
issues of the passed data. We can then extend this to handle the async
case by doing a _wait call with a spa_pending+callback+data that will
be called when the _enum_params returns and async result.
Add a sync method.
All methods can now return SPA_RESULT_IS_ASYNC return values and you
can use spa_node_wait() to register a callback when they complete
with optional extra parameters. This makes it easier to sync and
handle the reply.
Make helper methods to simulate the sync enum_params behaviour for
sync nodes.
Let the transport generate the sequence number for pw_resource_sync()
and pw_proxy_sync(). That way we don't need to keep track of numbers
ourselves and we can match the reply to the request easily.
