
<html><head></head><body>Hi,<br><br>The counter argument is that we don't clobber LibVLC core with a large dependency. I already added and then was rightfully forced by the others to remove gcrypt in the past for that exact same reason. Currently, LibVLC core only depends on system/compiler libraries (c, rt, pthread, iconv, resolv, etc) or substitutes (idn).<br><br>The argument against putting a generic API is that you have to link tons loads of algorithms, regardless of how many you actually need, since the unused algorithms cannot be eliminated at link time.<br><br><div class="gmail_quote">Le 29 mai 2019 13:25:16 GMT+03:00, Francois Cartegnie <fcvlcdev@free.fr> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<pre class="k9mail">Le 27/05/2019 à 20:52, Rémi Denis-Courmont a écrit :<br>pt API is crap, Nettle should be used in new code. If you only<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">need a small set of algos, that's much smaller, thread-safe and error-free. If <br>you need a large set of algos, you are reinventing TLS and that's a not a good <br>idea anyway.<br><br>Writing a wrapper around libgcrypt will end up bad, like libxml.<br></blockquote><br>I don't see the counter argument for providing a generic API as I<br>suggested. Thit just allows replacing gcrypt backend in the end.<br><br>handle = vlc_hash_start(VLC_HASH_MD5)<br>/* if not hardcoded in core -> load a crypto module */<br>vlc_hash_push();<br>vlc_hash_finish(handle)<br></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>