- From: youennf via GitHub <sysbot+gh@w3.org>
- Date: Wed, 22 Mar 2023 17:10:28 +0000
- To: public-webrtc-logs@w3.org
> Won't we need to modify the MessagePort spec in some way to ensure that `CaptureController.onmessage`, which is proposed in [this comment](https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1406345920), is the target of `MessageEvent.source`? No change to MessagePort spec needed. The only change outside of WebRTC land would be to update MessageEventSource WebIDL type definition, which is already a known extension point since it is a union type. > Here is how I generally envision it happening without new hooks in the MessagePort spec: This proposed algorithm is very imprecise, it would be hard to implement it in an interoperable manner. It does not take into account that MessagePorts live in different processes for instance, or that capture lives in another process. I would tend to stick to how specs are currently written these days, something like: - Enqueue a task on the capturee queue that runs the following steps: - If capturee[capturedBy][capturerId] is undefined, abort these steps. - Fire an event blabla... If we were to do that at MessagePort level, we would need to update https://html.spec.whatwg.org/multipage/web-messaging.html#message-port-post-message-steps, ditto for implementations which would break isolation of MessagePort code from capture code. > the **capturee** might expose user-facing controls to produce action in the **capturer**. This seems reasonable and would call for exposing display capturer as its own object. Events in DisplayCapturer to expose change of capturer state would be a natural fit I think. It would integrate pretty well with the above slot based algorithms to provide precise and consistent state exposures to web pages. > Same class, not same object. I don't see it as an issue. Do you? It is not great to use the same class to represent two things that have different behaviours. > > 9 is not about behavior but about ergonomics. > > The level of complexity in the app code to handle navigation of the captured-tab would be staggering, and race-prone. This goes beyond mere ergonomics. Our opinions differ here, but at this stage, this is nothing more than opinions. In terms of ergonomics, code examples or similar would help. In terms of race conditions, deeper analysis of what is racy would be needed. -- GitHub Notification of comment by youennf Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/70#issuecomment-1479954529 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 22 March 2023 17:10:31 UTC