On Mon, 11 Aug 2014 18:34:23 -0400 Theodore Ts'o <ty...@mit.edu> wrote:
> On Mon, Aug 11, 2014 at 10:53:56PM +0200, wm4 wrote: > > > > To be fair, FFmpeg does its own "manual" symbol versioning by appending > > increasing numbers to function names. But the real problem are not > > these functions, but public structs. Imagine a new API user fighting to > > guess which fields in AVCodecContext must be set, or which must not be > > set. Seasoned FFmpeg developers probably don't know the horror. > > There are some best practices in API design; one of them is to > minimize public structs as much as possible. Instead, have blind > pointers which are handed back by an "initialize object" function, and > then have setter/getter functions that allow you to fetch various > parameters or flags which modify how the object behaves. This allows > you to add or deprecate new flags, configuration parameters, in a > relatively sane way. Yes. Unfortunately, central data structures are still public, and just making them opaque and adding accessors on top of them would lead to a major compatibility issue, and all developers using ffmpeg would complain big time. In fact, the API cleanup is an ongoing process, and is what causes the incompatibilities with each release. For example, a C library should have a consistent naming schema. FFmpeg/Libav decided to use AV and av_ as prefixes for all symbols in the public header files. This required fixing some symbols, which of course broke some applications. > I have this dream/fantasy where all of the energy over developing and > maintaining two forks was replaced by a spirit of cooperations and the > developers working together to design a new API from scratch that > could be guaranteed to be stable, and then applications migrated over > to use this stable, well-designed, future-proofed API. > > Call me a naive, over-optimistic dreamer, but.... :-) > > (And, the yes, the new API probably should be a bit higher level.) > > "Can we all just get along?" -- https://www.youtube.com/watch?v=1sONfxPCTU0 > > - Ted Yes, that would be nice. The FFmpeg/Libav split is mostly a political/social issue though: it seems some (not all) members from each side just can't deal with some (not all) members from the other side. How do you fix this? It seems impossible. (Also, btw.: sometimes the low level aspect of the libraries is simply needed. It's just that most applications would be better off with a more high level API.) _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
