Logging features for 1.1.x about azure-kinect-sensor-sdk

[wes-b]

Feedback from @skalldri

1. If it’s not too much trouble to add, I would find this useful. My tool has dynamic log-level reconfiguration during runtime, so being able to change the K4A log level when I get a ROS log-level change would be nice. I can un-register and re-register the callback function, but it would be nice to not have to.

(I suppose we could allow the registration API to be called with the same callback function and treat that as an update to the logging level for a runtime change that doesn’t require unregistration. Anyone think that would be useful?)

2. This sounds fine. I can build my own locks around the logging function, but there needs to be pretty clear documentation in the SDK docs / k4a.h that concurrent callbacks are possible.

The callback function will be invokable by any caller attempting to log. So if there are 3 threads running on 3 CPU, and all of then generate an error message at the same time, then all three of them can call into the users logging callback function at the same time. The user will need to protect against this.

[wes-b]

Feedback from @xthexder.

I don’t have any problems with a callback sort of system for this.

If we’re only going to support a single registered function, then maybe the API could be simplified to just set_debug_message_handler(), which would replace any existing handler, or unregister it if NULL. This would also make changing the log level easier if the user specifies the same function.

Needing to pass in the pointer to the existing callback function seems like an arbitrary requirement if it’s only possible to register a single callback.

-Jacob

[wes-b]

Feedback from @yijiew

The design sounds nice to me. But I am afraid we cannot leverage this nice feature in our body tracking SDK. Because body tracking SDK is created on top of the K4A SDK but not wrapping around it. In order to use the body tracking SDK, the user still requires to call the K4A APIs. Since the registration API will only allow 1 callback function to be registered, if we redirect the logging system to use our own callback function, the logging behavior will be strange when the user directly calls the K4A SDK.

[wes-b]

@skalldri thanks for the feedback, I will plan to allow runtime changing of logging level.

@xthexder I like the idea of calling this k4a_set_debug_message_handler() and using the same API to clear it. This is the same as k4a_capture_set_XXX_image() to add and clear an image.

@yijiew You should consider implementing the same k4a_set_debug_message_handler() API, which will allow the user to forward BT and SDK messages to the same tool owned by the user.

[schultetwin1]

I love this. As an FYI for getting started, spdlog has an idea of sinks. We may want to do this by creating a custom sink which is just a callback.

Someone tried to create a callback sink in spdlog a couple years ago but the PR was denied because it was too specific for the spdlog library. Even though it was rejected, it might be interesting to see how they did it as a starting point.

PR can be found here: https://github.com/gabime/spdlog/pull/205/files