- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Jun 2022 19:45:09 +0000
- To: public-webrtc-logs@w3.org
> 2\. During today's Editors' meeting, @jan-ivar and @youennf have been opposed to merging this PR. Here are some thoughts that have been shared during this editor's call: 1. This PR needs more work to be merged. I made for instance the comment that the new check should be done asynchronously. @jan-ivar mentioned a different error type would be better. 2. My position on this particular issue is not set yet, this issue was filed 2 days ago and I was surprised the goal was to merge it today. Pushing back on merging this PR is not a hint on what my position will be. 3. It does not seem like we need to rush this PR like we did rush the fromElement PR. fromElement has much more consequence than this PR, so it is not great but ok to rush it. Here, it seems ok to take some time. I would personally prefer if we would allocate time on the async/sync discussion instead of those issues. 4. This PR does not seem like a blocker for shipping Chrome implementation (?) 5. There are some arguments for/against this PR, it seems worth evaluating them. Let's take the time to discuss these arguments before merging the PR instead of after. With regards to 4 (the most interesting part of the discussion), some more thoughts, either shared during the call or not: 1. It seems that most specs are not describing algorithms to that kind of details. Maybe this is the first time we are trying to do so and we try to create a pattern. Or maybe this is an existing pattern that has been discussed and validated in other specs and we are just applying it here. Let's clarify this. 2. Resource limitation is quite vague in general so it is unclear how this helps interoperability or how this is supposed to help web applications. Let's dig into that. 3. getUserMedia/applyConstraints have similar resource limitation concerns but we do not say anything there AFAIK. Maybe we should say something there as well, or maybe this is not in practice a big deal. Let's clarify this. 4. It seems that this PR is at least partially trying to cover a limitation of Chrome's current implementation with regards to clone/cropTo. From what I understood, this limitation is more a bug than a desired behavior. I do not feel this alone justifies changing the spec, especially this early in the specification/implementation process where the trade-off end goal/reality is a bit more on the end goal side of things. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-region/pull/54#issuecomment-1145275509 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 June 2022 19:45:11 UTC