Re: [mediacapture-handle] Should the handle be an object? (#68)

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]( 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](, which seems necessary to handle arbitrary objects (e.g. [FileReaderSync]( and several other objects cannot be instantiated in Window). postMessage has [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](, 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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Thursday, 2 February 2023 17:37:04 UTC