On Mon, 29 May 2017 12:03:26 +0200 Diego Biurrun <di...@biurrun.de> wrote:
> *PLEASE* do not bottom-post. > > On Mon, May 29, 2017 at 11:32:49AM +0200, wm4 wrote: > > On Mon, 29 May 2017 10:56:36 +0200 > > Diego Biurrun <di...@biurrun.de> 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. > > > Why do you insist on not using this modularization, and instead > > doing it in tricky ways like #including .c source files? > > The .c #include is just a detail of this patch and not particularly > hard to change. So how would you change it. You'd just end up with a modification of the URLProtocol struct anyway. _______________________________________________ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
