- From: Elad Alon via GitHub <sysbot+gh@w3.org>
- Date: Thu, 22 Feb 2018 20:05:39 +0000
- To: public-webrtc-logs@w3.org
Taylor, * The problem is that webrtcLoggingPrivate API lives in a separate process than the renderer process. If the JS in the renderer process cannot see any ID, it cannot refer to a specific peer connection when calling any of the functions in webrtcLoggingPrivate. * I didn't mean one tab would be rate limiting another. I was trying to give an example of another possible use to RTCPeerConnection.id. In this hypothetical case, the decision to rate limit comes from the JS application in the renderer process, but needs to go to the browser process, which is in charge of network IO. It's true that the API could in theory live in the renderer process, but it could also live in a separate process, as is the case for webrtcLoggingPrivate, in which case, having a single way of saying "peer connection X" would benefit us. * Unless you feel it would really help, I would prefer not to write pseudo-code for a made up example, because we have the IMHO much more informative example of a real case. Please see these two CLs, the first of which introduces the ID attribute, and the second of which uses it: * https://chromium-review.googlesource.com/c/chromium/src/+/923986/4 (Specifically look at PS4; I have mis-edited PS5 and didn't have time to fix before leaving the office.) * https://chromium-review.googlesource.com/c/chromium/src/+/931081/ -- GitHub Notification of comment by eladalon1983 Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1775#issuecomment-367805166 using your GitHub account
Received on Thursday, 22 February 2018 20:06:11 UTC