- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Mon, 13 Feb 2023 14:51:31 +0000
- To: public-webrtc-logs@w3.org
> From its algorithm, it looks like messages can get missed due to timing. How are [the events](https://w3c.github.io/mediacapture-handle/identity/index.html#events) insufficient for ensuring that nothing is missed? > There's no surfacing of deserialization errors, * Presently, no serialization errors can occur, because we only accepts strings. * If we extend along the lines of [this approach](https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1282898580), no serialization errors are possible either. * If we change the [handle](https://w3c.github.io/mediacapture-handle/identity/index.html#dom-capturehandleconfig-handle) to be `object` or `(DOMString or object)`, we can specify that [setCaptureHandleConfig()](https://w3c.github.io/mediacapture-handle/identity/index.html#set-capture-handle-config) can raise a synchronous error if it cannot guarantee that the object is serializable. That seems simple enough, does it not? > this would seem to go against § 7.7. Use plain Events for state, As mentioned, I don't see any problems with the current approach; in fact, you have yourself convinced me to stop exposing the message on the event, because we both agreed it was unnecessary - see [here](https://github.com/w3c/mediacapture-handle/issues/50). But assume for the sake of argument that adding the message back were necessary. The first words in `§ 7.7. Use plain Events for state` are: **"Where possible"**. -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/mediacapture-handle/issues/68#issuecomment-1428069235 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 13 February 2023 14:51:33 UTC