> On 20 Nov 2017, at 13:35, nablet developer <s...@nablet.com> wrote: > > >> >> Thanks for explaining. I think it is not the best decision. >> >> The reason the socket API resembles TCP is because all the sockets API >> resemble each other, since they are based on the old BSD socket API. And >> the protocol handlers of libavformat too. >> >> Therefore, I think all the trampoline code to allow TCP to call back >> another protocol plus all the boilerplate code that you need to make >> opensrc callable from TCP amounts to worse than implementing a protocol >> directly. >> >> Furthermore, TCP is the most important network protocol for now, while >> opensrt is still rather obscure, so tying one with the other is not a >> good idea. >> >> Also, implementing a real protocol from scratch would possibly allow you >> to make use of extra features of the opensrt API: maybe they have a >> read-with-timeout function, for example, or something like that. >> >> > > thanks for the feedback. > regarding relying on TCP protocol code it's clear - I will implement protocol > from scratch next time. > regarding re-using functions from network.c (like ff_network_wait_fd, > ff_accept, etc) > is suggested approach acceptable? is it okay to define such socket_api > structure and pass to > network.c calls? >
ping _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
