On Mon, 29 May 2017 12:39:12 +0200 Diego Biurrun <[email protected]> wrote:
> On Mon, May 29, 2017 at 12:18:22PM +0200, wm4 wrote: > > On Mon, 29 May 2017 12:03:26 +0200 > > Diego Biurrun <[email protected]> wrote: > > > On Mon, May 29, 2017 at 11:32:49AM +0200, wm4 wrote: > > > > On Mon, 29 May 2017 10:56:36 +0200 > > > > Diego Biurrun <[email protected]> wrote: > > > > > --- > > > > > > > > > > Log message still not perfect. > > > > > > > > > > No longer tries to deduplicate parts of the implementation, just > > > > > disentangles > > > > > the protocol declaration. > > > > > > > > > > configure | 8 ++------ > > > > > libavformat/Makefile | 3 +-- > > > > > libavformat/network.c | 20 -------------------- > > > > > libavformat/protocols.c | 3 +-- > > > > > libavformat/tls.c | 39 > > > > > ++++++++++++++++++++++++++++++--------- > > > > > libavformat/tls.h | 8 -------- > > > > > libavformat/tls_gnutls.c | 31 ++++--------------------------- > > > > > libavformat/tls_openssl.c | 31 ++++--------------------------- > > > > > libavformat/utils.c | 4 ++++ > > > > > 9 files changed, 46 insertions(+), 101 deletions(-) > > > > > > > > We have a perfectly fine way to modularize protocols (or protocol > > > > "filters", like TLS, encryption, etc.) - and we're using it in a good > > > > way. > > > > > > Example? > > > > Like I said, TLS protocols, encryption, any other form of nested > > protocols. Nested protocols are the libavformat abstraction to use for > > this, and TLS fits quite well into it. > > > > It works by giving each TLS implementation its own URLProtocol, which > > the current code does. > > > > I don't know what your patch is trying to achieve. > > Fix the bug(s) in your splitting of tls.c. tls_protocol no longer exists > but is referenced in configure. Nested protocols may be a nice abstraction > but it should not change the way users have to configure a build. There > should be one way to enable/disable the TLS protocol, not two now and > possibly four different ones in the future. Then why not fix configure instead? _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
