[Webkit-unassigned] [Bug 158832] WebRTC: Replace RTCPeerConnection custom constructor with a JS built-in constructor

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Mon Jun 20 22:29:16 PDT 2016


https://bugs.webkit.org/show_bug.cgi?id=158832

--- Comment #7 from Adam Bergkvist <adam.bergkvist at ericsson.com> ---
(In reply to comment #6)
> Comment on attachment 281665 [details]
> Updated patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=281665&action=review
> 
> > Source/WebCore/Modules/mediastream/RTCPeerConnection.cpp:83
> > +    Document& document = downcast<Document>(*scriptExecutionContext());
> 
> It might be better to use CallWith=Document in the IDL to pass Document as
> parameter to the IDL

Fixed.

> > Source/WebCore/Modules/mediastream/RTCPeerConnection.h:66
> > +    void initializeWith(const Dictionary& rtcConfiguration, ExceptionCode&);
> 
> Is "rtcConfiguration" needed?

It contains all the settings passed to the constructor.

> > Source/WebCore/Modules/mediastream/RTCPeerConnection.js:44
> > +        this. at initializeWith(configuration);
> 
> I am not quite sure but can we find a better handling of errors than
> catching-and-rethrowing?
> Would it be more readable to make initializeWith return a status code
> instead?

I agree that catching and re-throwing is not ideal and that we should aim for something nicer. My plan is to revamp the RTCPeerConnection constructor, and probably the related setConfiguration() method, entirely in [1] to make them spec compliant. We probably want to define the RTCConfiguration dictionary (argument to constructor and setConfiguration()) properly in IDL or do something in the JS built-ins to get nice error messages. So further tweaks to this code will most likely be throw away soon. Is it OK going forward with that plan and commit this to unlock the blocked bugs?

[1] http://webkit.org/b/158936

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160621/065a8248/attachment.html>


More information about the webkit-unassigned mailing list