Tomas Härdin (12023-07-31): > 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.
You are missing the point: even if all these features are entirely disabled (which we cannot be really sure), the code and data structure have to be designed to make them possible. That means significantly more complex code, much more prone to bugs, including security-relevant. > It is foolish to spread scarce developer time more thinly. For that, see below. > It almost certainly means worse security, not better. I am quite sure your estimation in this is wrong. > 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? > > 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. You are neglecting a very important point here: The time of other people is not yours to count. You are not a boss directing the time of your employees towards the task most profitable for you. Michael is not hacking software defined radio to be profitable for somebody, he is having fun with it (probably because he recently got his hands on the hardware). And I want to write a <foo bar="qux"> parser because it is an interesting challenge. But since Michael is a very talented hacker, the result of he having fun ends up being code that is in some way already better than existing alternatives. As a member of a community project, you do not have the authority to choose what other developers work on. The only authority you have is to decide whether you will welcome the fruit of their work as an useful new feature (while being vigilant about code quality) or whether you will be so annoying about it that they give up trying to contribute to FFmpeg. As of now, you seem to be making the wrong choice. And I can tell you about my own situation: for several months now, the attitude of some developers here, including you very strongly, has mostly disgusted me from contributing to FFmpeg. The stupid farmer kills the goose with the golden eggs by opening up her belly. The smart farmer kills the goose with the golden eggs by trying to force her to lay on a schedule. > Layering is not an end in itself as you rightfully point out. It is a > tool. To what end? > 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. As you point: layering is not an end. “The scope” is not the reason, it is only a quick summary of the reasons when they are obvious and we all agree. So please stop invoking “the scope” as a reason. Second, layering is indeed something to wish for in a complex project, but it has to come organically, it has to appear progressively as the code becomes more complex and the useful boundaries and interfaces appear. When people start with layering, the result looks like the OSI model for network stacks: it makes a few nice paragraphs in textbooks and is completely worthless in practice. > 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. It is the second time you say this, and it is the second time I have to tell you: no, it is not true at all. We are seeing exactly the opposite: Michael's code is big, but it is self-contained and completely optional. Furthermore, it is not wasting any developer time. Only these sterile objections are wasting precious time. -- Nicolas George _______________________________________________ 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".
