- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Jun 2022 20:29:08 +0000
- To: public-webrtc-logs@w3.org
> 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. Thanks. I've made that change. > 2. My position on this particular issue is not set yet Then I have misunderstood you during the meeting. Apologies for misrepresenting your position here. > 3. ... I don't think we rushed anything yet. This PR is indeed only two days old, so go ahead and take your time. > 4. This PR does not seem like a blocker for shipping Chrome implementation (?) Probably not. > 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. Let's. --- > 1. ... 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. ... I am not sure, but hopefully people more experienced than me would know. > 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. I see it as intentionally general, covering any implementation-specific limitation that prevents a browser from changing cropping at a given time. It gives developers predictability and interoperability in detecting otherwise-unexpected errors, without requiring us to discuss every newly-discovered implementation issue we encounter in the future. (If certain errors do become interesting enough to merit special treatment, we can specify later that these specific issues get handled differently.) > Maybe we should say something there as well, Maybe. Wdyt? Should we? > or maybe this is not in practice a big deal. Even if it's not a big deal, specifying it seems better than leaving it unspecified. See more below. > I do not feel this alone justifies changing the spec If other implementations run into their own set of idiosyncratic limitations, they will be glad to discover that there is a predictable way of failing, and that developers are already aware of that type of failure. When the spec is aligned with implementations, everyone benefits. --- > I believe @dontcallmedom and @aboba are working on clarifying rules of engagement in github issues for our WG That's great. Please let me know if there's anything in the engagement around this issue thus far, that you think could be improved. > We have an interim meeting on Tuesday, so I'm going to focus on slides for #17. I am not sure I'll be able to attend. I regret that the intention to discuss #17 was announced only today, or I would have cleared my schedule ahead of time. (As of earlier today, no agenda items were announced.) I'll try to shuffle around my other commitments and make it. But if I cannot, I suggest that it might be more productive to discuss Region Capture during an interim meeting which I can attend. For your consideration. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-region/pull/54#issuecomment-1145311007 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 20:29:10 UTC