- From: Jan-Ivar Bruaroey via GitHub <sysbot+gh@w3.org>
- Date: Tue, 08 Nov 2022 23:41:03 +0000
- To: public-webrtc-logs@w3.org
> The first broadcast API has some benefits: Great to hear! > It also has some downsides: > - It is a replacement to an existing API, no new functionality really. Being able to pass real messages, even objects (like cropTargets), would be new functionality (solving #11 and #68). [BroadcastChannel.postMessage](https://html.spec.whatwg.org/#dom-broadcastchannel-postmessage) shows [StructuredDeserialize](https://html.spec.whatwg.org/#structureddeserialize) can fail, and fires a [`messageerror`](https://html.spec.whatwg.org/#event-messageerror) event. Don't we need to solve that here? Design principle [§ 2.4. Be consistent](https://www.w3.org/TR/design-principles/#consistency) urges us to not reinvent what has been solved. > - The implicit message to cache on capturee side so that new capturer can get the event is not really aligned with postMessage and seems surprising/a bit awkward. Every shape has tradeoffs, but a broastcast postMessage with a delay seems less awkward than [a getter + event that can be abused as postMessage using setTimeout()](https://github.com/w3c/mediacapture-handle/issues/11#issue-1133223150). Recall that [BroadcastChannel](https://html.spec.whatwg.org/#broadcastchannel) already sends messages into the ether, with no guarantee of recipients, time of delivery, or response (users open and close documents). In that light, having the last burst delivered to new listeners added since the burst — while certainly new distinct behavior we'd define because it's useful — doesn't seem model-breaking, because it doesn't seem to violate any guarantees one might rely on. IOW, where it differs, it's useful. There are already 3 `postMessage` functions whose functionality vary significantly because it's useful. Is this difference larger than those? > There is no way to understand/ensure that two successive messages are coming from the same capturer. This might be error prone (although rare in practice). Check `e.origin`? This should be a known pattern, an advantage of using a familiar postMessage shape. > Another approach to look at is something like HTML History state (which is using structure clone, like we could do for capture handle). This seems closer to what we are trying to model. Happy to consider other proposals! Maybe in a separate issue? > One area to study before we try to dive into APIs is what happens when capturee navigates to a new document The user agent could post a blank message on navigation, replacing [capturehandlechange](https://w3c.github.io/mediacapture-handle/identity/index.html#dfn-capturehandlechange). -- GitHub Notification of comment by jan-ivar Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/69#issuecomment-1307983217 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 8 November 2022 23:41:07 UTC