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. 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 _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
