Re: [webrtc-pc] RTCPeerConnection lacks identity marker beyond current process

> I have a use case where peer connections are produced in one process (namely Chrome's renderer process), but I then need to refer to them on another process ("perform this and that on peer connection this and that"). The latter instruction should originate from the renderer process (where JS code lives).

This seems like a Chrome implementation detail that could be handled by adding an ID to the internal (C++) PeerConnection object. But why would it need to be exposed to JS?

> To give some made-up examples, it could be that one browser wants to allow an API that would rate-limit a given peer connection, and another browser wants to add an API that limits the time that a peer connection may remain open. Normally, this would be achievable with just giving a reference to the `RTCPeerConnection` object, so no problem. But this assumes a specific structure of the hosting application. Namely, it assumes that the application is single-process, and that the API called for "please rate limit X" is the same process where X lives. Normally, this assumption is true. But not always.

I'm confused. Are you saying you want the ability for one tab to rate-limit a PeerConnection owned by another tab, using an API like:

```void setPeerConnectionRateLimit(DOMString id, int kbps);```

But you'd still need some inter-tab communication mechanism to communicate the ID from the tab that owns the RTCPeerConnection to the one controlling the rate-limiting. And if such a communication mechanism exists, why couldn't it be used in the reverse direction, to send a message saying "rate-limit your PC". In which case the API could go directly on `RTCPeerConnection`:

partial interface RTCPeerConnection {
    void setRateLimit(int kbps);

Sorry if I'm completely misunderstanding your use case. Maybe you could give a more specific example, with some pseudocode?

GitHub Notification of comment by taylor-b
Please view or discuss this issue at using your GitHub account

Received on Tuesday, 20 February 2018 22:26:57 UTC