sön 2023-07-30 klockan 15:04 +0200 skrev Nicolas George: > That means every time we use a real XML library to parse > “<foo bar="qux">”, we pay the price for the complexity of the whole > language, in terms of efficiency, reliability, security exposure.
As far as I recall libxml2 does not enable the fancier features of XML unless told to do so. And if it can't disable things like DTD then a ticket should be opened with them to make that possible. It is foolish to spread scarce developer time more thinly. It almost certainly means worse security, not better. The same goes for all things that FFmpeg reimplements. HTTP has already been mentioned. How many developer hours have been wasted on it when libcurl could be used instead, and a fraction of those hours going to improving it rather than a duplicate implementation? Layering is not an end in itself as you rightfully point out. It is a tool. To what end? I have been accused of being a "bean counter". But what are these beans that I count? They are developer time, the sole source of value of the free software movement as a whole. When I see things like HTTP or MXF being reimplemented I don't see features. I see liabilities. In the free software world we don't layer and segregate things for no reason. We do it so that programs can interact with each other through standardized interfaces. The effect is a comedy of the commons. More can be done with less labour. For an FM receiver program the appropriate interfaces are ALSA, PulseAudio and/or JACK. That way its audio can be piped to many programs. It is true that we can add more features, and it is also certainly true that these are useful for a non-empty set of users. But is it a good use of scarce developer time? Were SDR limited to only Michael's time then there would be no problem. But it isn't. It unavoidably touches many other parts of the code, as we are already seeing. /Tomas _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".