On Fri, 26 May 2017, Hendrik Leppkes wrote:

On Fri, May 26, 2017 at 7:27 PM, Diego Biurrun <di...@biurrun.de> 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).

+1, this is the way to go, not messing them back up into one c file. I was in favour of the ifdef mess I created originally, but I'm no longer in favour of that. I do want the schannel and securetransport implementations, I just haven't had time to attempt to cherrypick them.

// Martin
_______________________________________________
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Reply via email to