[vlc-devel] [PATCH 0/2] Libvlc formatted log callback
rom1v at videolabs.io
Wed May 22 19:47:29 CEST 2019
Le 21 mai 2019 22:34:31 GMT+02:00, Jeremy Vignelles <jeremy.vignelles at dev3i.fr> a écrit :
>After reading through the comments, I think it is a good idea to sum
>== The issue ==
>`libvlc_log_set` is a good API that can register log callbacks.
>An application using libvlc is able to get log messages, format them,
>and either show them to the user, or write them to a file.
>This is great when the application is written in C, or uses an
>intermediate layer written in C.
>However, the current shape of the API makes it hard to call from
>languages calling libvlc through FFI, because of the va_list argument.
>For a language like C#, there is no easily-accessible vsnprintf
>equivalent on all platforms that supports all formatted string markers.
>LibVLCSharp, the official libvlc binding for .net, is impacted by this
>issue because it can't offer a binding for libvlc_log_set to C# users.
>== What can we do about it? ==
>= Leave things as-is =
>+ Keeps compatibility with existing apps
>+ conforms to what is done in other libraries, like libavutil
>+ does not add allocation overhead (No allocation means no malloc
>- Requires higher-level languages to have a native glue code, built for
>each platform libvlc will be used on, which is a hard work for bindings
>= Keep libvlc_log_set, but add a formatted log callback next to it =
>+ Keeps compatibility
>+ Adds ability to consume from other languages
>- Might create confusion about which API to call
>- libvlc_instance_t.log will need to keep track of the two forms of log
>callback, which I don't find really clean.
>= Use the v2 of the patch : Remove libvlc_log_set and use a
>preformatted log callback instead =
>+ Solves the issue, and makes the API easier to consume from any
>language using libvlc from FFI.
>+ Keeps only one logging API
>+ Allows to filter by log level before formatting the log.
>- Breaks the libvlc logging API
>= Introduce a libvlc_vsnprintf that can format log message the way
>libvlc expects? =
>+ Cross-platfrom solution
>+ Higher-level languages could probably pass the args as a pointer (not
>sure about this one, this will need to be checked)
>+ Doesn't touch the libvlc_log_set API and let the user decide how
>things are formatted.
>- Adds marshalling overhead
>- The API has nothing to do with libvlc's main purpose.
I like the last one, the current usage is not affected at all.
>Did I miss something? Has anyone other ideas/objections?
>What's your preference everyone?
>vlc-devel mailing list
>To unsubscribe or modify your subscription options:
More information about the vlc-devel