Open ropieur opened 2 years ago
You are right, there is currently no way to discover the registered sinks after initializing the logging library. I would like to rectify this, but it's not clear how to do this to make it a useful feature.
Sinks, formatters and filters that are registered in the core with erased types. For example, the core operates on sinks through a pointer to sink
interface, which is useful for feeding log records but not much else. The core, or the setup helper function, cannot produce a pointer to the actual sink that derives from this interface, like synchronous_sink<text_file_backend>
for instance. It could produce a pointer to sink
, which would require the user to use whatever means to discover the actual type of the sink, which doesn't look very useful.
Hi @Lastique , I guess that this kind of extension will not pop up in a short term. Do you have suggestions how I could proceed meanwhile?
One workaround would be to register your own sink factories that will remember the sinks they create.
Hi, I would need to allow my application to provide to the end user with a dynamic control on sinks configured in settings file (typically, change the filtering at runtime). For that, I would need to have to list of the configured sinks, but from my searches results on the web, it looks like there is no such a support.
Would it be possible to add the support for querying and visiting the sinks? If not, what alternative solution would you suggest (if possible, without having to reimplement setup file parser)?
Thanx in advance