- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Thu, 02 Feb 2023 17:37:02 +0000
- To: public-webrtc-logs@w3.org
I sense generally good agreement on the use case here, with the only differences being over API shape. This seems like something we should be able to make progress on. My concerns that I don't believe have been addressed here are: 1. Calling [setCaptureHandleConfig](https://w3c.github.io/mediacapture-handle/identity/index.html#dom-mediadevices-setcapturehandleconfig) rapidly doesn't seem web compatible wrt what a capturer sees. From its algorithm, it looks like messages can get missed due to timing. postMessage solves this using a queue. 2. There's no surfacing of [deserialization errors](https://github.com/w3c/webcodecs/issues/635#issuecomment-1412798059), which seems necessary to handle arbitrary objects (e.g. [FileReaderSync](https://www.w3.org/TR/FileAPI/#FileReaderSync) and several other objects cannot be instantiated in Window). postMessage has [onmessageerror](https://html.spec.whatwg.org/#handler-window-onmessageerror) for this. While (1) might be addressed by adding the message to the event, this would seem to go against [ยง 7.7. Use plain Events for state](https://w3ctag.github.io/design-principles/#state-and-subclassing), perhaps suggesting that recreating (post) message-passing behavior using events is not a desirable pattern. -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1414120568 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 2 February 2023 17:37:04 UTC