On 9/8/16 1:18 PM, Andrew Swan wrote:
First, I read through bug 1189060 in which the webrtc extension hooks were created. I'm concerned that I can't actually hook into the PeerConnection establishment process in a safe way. If extension A overrides webrtcUI.receiveMessage in the suggested manner, then extension B does the same, everything is fine. But then if extension A is unloaded, there's no way for it to unchain its handler. It can detect this at unload time but it can't actually do anything. Would a patch to address this situation be accepted? Who would be the right person to review such a patch? (Incidentally, I searched through the addons from addons.mozilla.org <http://addons.mozilla.org> that are indexed on DXR and there are none in the index that are using this hook, but we don't yet have everything from AMO indexed in DXR. That's all to say, I don't think there's a compatibility issue with changing the interface for this hook.)
As you point out, this hook is currently used only very lightly today -- mostly likely because the existing documentation consists entirely of the hacks post you mentioned. I think that breaking changes should probably be okay.
The necessary reviewers for your patch would depend greatly on which parts of the system you touch. The patches in 1186060 hit many modules, and ultimately had reviews from florian, fabrice, mfinkle, mt, peterv, and khuey. For changes in the webrtc module, I'd ask jib for reviews (rather than mt). For changes in DOM, probably bz (rather than khuey) Any other modules, I'd tag one of the 1186060 reviewers, since they'll have context.
Second, looking past PeerConnection, what other things might we want to expose to extension authors? In the description for bug 1281833, Adam suggests "The ability to add, remove, or change IP addresses exposed by PeerConnections". This sound like a useful thing but I'm unfamiliar with the webrtc implementation, is this even feasible? What other things can/should we expose?
What I'd expect here is the means to register a callback that is hit whenever a new ICE candidate is generated. The callback receives the candidate, and returns a Promise<void>. Once it reaches a verdict on whether the candidate is allowed to be presented to the content, it either resolves or rejects the promise. (Or, if people don't like the aesthetics of a promise reject for normal operation, you can return a Promise<boolean>).
I'm actually not sure what I had in mind when I said "add" and "change", since this... won't be useful. Conveying addresses that the ICE stack isn't listening on would only make connection setup take longer and/or fail.
-- Adam Roach Principal Platform Engineer [email protected] +1 650 903 0800 x863 _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
