On Fri, May 26, 2017 at 7:27 PM, Diego Biurrun <[email protected]> wrote: > On Fri, May 26, 2017 at 03:12:43PM +0300, Martin Storsjö wrote: >> On Fri, 26 May 2017, Diego Biurrun wrote: >> >--- >> >TLS is not handled like other protocols. Instead the implementation details >> >of which crypto library is used get exposed to the user. Hiding those >> >details allows simplifying and refactoring some code and avoiding the >> >special-casing of TLS. >> > >> >This should get a slightly more elaborate log message before pushing. >> > >> >configure | 8 ++---- >> >libavformat/Makefile | 3 +- >> >libavformat/network.c | 20 -------------- >> >libavformat/protocols.c | 3 +- >> >libavformat/tls.c | 70 >> >+++++++++++++++++++++++++++++++++++++++++------ >> >libavformat/tls.h | 8 ------ >> >libavformat/tls_gnutls.c | 53 +++-------------------------------- >> >libavformat/tls_openssl.c | 53 +++-------------------------------- >> >libavformat/utils.c | 4 +++ >> >9 files changed, 77 insertions(+), 145 deletions(-) >> >> Doesn't this partially revert parts of what was done in >> d8ffb2055f0e0fcb5d025bab72eb19c2a886c125? While I was the one who originally >> wrote in the way it was with all of the gnutls and openssl implementations >> all in tls.c, I don't want this code to be moving back and forth, and I now >> enjoy the clarity of having them cleanly separated. > > It partially does revert the commit now that I have looked at it, but I don't > really see a problem. The lib-specific code remains in separate files, just > the shared bits are refactored and the ff_tls_foo --> ff_tls_gnutls_foo > indirections are avoided... >
If someone were to port the windows schannel TLS implementation or the OSX securetransport implementation (which someone might want to, since its nice to not depend on external libs if possible), then your read and write functions would end up full of ifdefery, especially since those two have more then one single call in them. I'm in favor of keeping them entirely separate, instead of partially ifdeffing things and using .c includes (which are always a bit iffy, if you ask me). - Hendrik _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
