Mark Thompson (12021-02-20): > I'm not entirely sure where this discussion was going, but I believe > the original questions would have been simple to answer if anyone had > bothered to read the documentation. > > Adding a file descriptor referring to something independent of libuv > (such as an alsa or xcb fd) is handled by uv_poll_init(), see > <http://docs.libuv.org/en/v1.x/poll.html>.
I had looked in the documentation, but not read it entirely, and I had missed this part. I was precisely to get help finding the relevant tidbits that I asked here. I want to take the occasion to explain how this discussion is going, in my opinion. Lynne, this is in great part for you. When I exposed my prejudices against Node, it was not to close the discussion, it was not a rejection. Quite the contrary, I was opening the discussion, I was inviting precisions: I pointed that my prejudices were weak, and that I knew they were, and I expected somebody to correct me with more accurate information relevant to the discussion. Somebody could have pointed to me that the horrible strace output of Node is not the fault of libuv, that libuv does all the necessary things to use efficiently the available system features. (About my opinions on industrial development, I believe they are founded, but they are not relevant, as they relate to practices that are commonplace there, but are absolutely not what libuv does.) Now that I have looked into it more carefully, I can say that libuv seems pretty good. Apparently, it does the right thing wherever I looked. In fact, what libuv does looks a lot like what I want to do with libavformat. If we were looking for a library to found our network protocols upon, then libuv would be probably an excellent candidate. But that is not what we are doing. The policy of this project has always been: no hard dependencies for core features. Network protocols are a core feature, at least some of them. We cannot depend on libuv for them. There is another policy: we do not chose a side. We do not decide if OpenSSL is better than GnuTLS, we support both. For these reasons, we are not looking for a single library to base the protocols. We will do that ourselves, and we are looking for libraries to bring extra features and most importantly to prove that the new design is usable with them. The last point is very important. Even if we finally decide to go with libuv, we must make sure that other applications will be able to use libev, and GLib/Gtk+, and Qt. And that means we cannot use the advanced features of the libraries, we need to stay with the basic features that are available, one way or another, in all of them. I know that GLib/Gtk+, libev and Qt are compatible with each other and with the design that is immediately obvious for an experienced Unix developer. This is what I intended to do. For a time, it seemed that libuv was not compatible, not compatible with GLib/Gtk+, libev and Qt and not compatible with the obvious design. That would have meant it was too high-level for our needs. That would have removed a promising option from our choices, but that would not have been terrible. Fortunately, Mark found the bit that was missing, so we can go ahead. But there was another option, and there still is. We can decide to change the policy. We can decide that the way libuv does things is good, and we want to use it, and FFmpeg will depend on it to become better. This is not what we were discussing, but we can discuss it. I have no intention of undertaking this discussion, but I think it could be a good idea, and I would not oppose it, quite the contrary. So, Lynne, if you want to defend this change in policy, please go ahead, you have my support. But otherwise, it seems we can use libuv, but we will still have to restrict to its basic features. I hope this makes things clearer and removes any aggression that may have seeped into the discussion. Regards, -- Nicolas George
signature.asc
Description: PGP signature
_______________________________________________ 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".