third_party/WebKit/Source/modules/mediastream/RTCCertificate.idl - Issue 1373023002: RTCCertificate, RTCPeerConnection.generateCertificate (WebRTC JavaScript) added.

Side by Side Diff: third_party/WebKit/Source/modules/mediastream/RTCCertificate.idl

Issue 1373023002: RTCCertificate, RTCPeerConnection.generateCertificate (WebRTC JavaScript) added. (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Make trybots compile (WebRTCCertificate not including wtf/Noncopyable) Created 5 years, 2 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

« third_party/WebKit/Source/modules/mediastream/RTCCertificate.h ('K') | « third_party/WebKit/Source/modules/mediastream/RTCCertificate.cpp ('k') | third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.h » ('j') | third_party/WebKit/Source/modules/mediastream/RTCPeerConnection.h » ('J')
Toggle Intra-line Diffs ('i') | Expand Comments ('e') | Collapse Comments ('c') | Hide Comments ('s')

OLD	NEW
1 /*	1 /*

2 * Copyright (C) 2012 Google Inc. All rights reserved.	2 * Copyright (C) 2015 Google Inc. All rights reserved.

3 *	3 *

4 * Redistribution and use in source and binary forms, with or without	4 * Redistribution and use in source and binary forms, with or without

5 * modification, are permitted provided that the following conditions	5 * modification, are permitted provided that the following conditions

6 * are met:	6 * are met:

7 *	7 *

8 * 1. Redistributions of source code must retain the above copyright	8 * 1. Redistributions of source code must retain the above copyright

9 * notice, this list of conditions and the following disclaimer.	9 * notice, this list of conditions and the following disclaimer.

10 * 2. Redistributions in binary form must reproduce the above copyright	10 * 2. Redistributions in binary form must reproduce the above copyright

11 * notice, this list of conditions and the following disclaimer	11 * notice, this list of conditions and the following disclaimer

12 * in the documentation and/or other materials provided with the	12 * in the documentation and/or other materials provided with the

13 * distribution.	13 * distribution.

14 * 3. Neither the name of Google Inc. nor the names of its contributors	14 * 3. Neither the name of Google Inc. nor the names of its contributors

15 * may be used to endorse or promote products derived from this	15 * may be used to endorse or promote products derived from this

16 * software without specific prior written permission.	16 * software without specific prior written permission.

17 *	17 *

18 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS	18 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

19 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT	19 * "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT

20 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR	20 * LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR

21 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT	21 * A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT

22 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,	22 * OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,

23 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT	23 * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT

24 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,	24 * LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,

25 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY	25 * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY

26 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT	26 * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

27 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE	27 * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE

28 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.	28 * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

29 */	29 */

30	30

31 callback interface RTCSessionDescriptionCallback {	31 [
	philipj_slow 2015/10/08 08:32:31 Can you link to http://w3c.github.io/webrtc-pc/#rt Can you link to http://w3c.github.io/webrtc-pc/#rtccertificate-interface above the interface? hbos_chromium 2015/10/14 13:00:50 Done. Show quoted text On 2015/10/08 08:32:31, philipj wrote: > Can you link to http://w3c.github.io/webrtc-pc/#rtccertificate-interface above > the interface? Done.
32 void handleEvent(RTCSessionDescription sdp);	32 GarbageCollected,

	33 NoInterfaceObject,
	philipj_slow 2015/10/08 08:32:31 The spec doesn't have [NoInterfaceObject]. The spec doesn't have [NoInterfaceObject]. hbos_chromium 2015/10/14 13:00:50 Done. Nice catch. Show quoted text On 2015/10/08 08:32:31, philipj wrote: > The spec doesn't have [NoInterfaceObject]. Done. Nice catch.
	34 RuntimeEnabled=RTCCertificate

	35 ] interface RTCCertificate {

	36 // The date and time after which the certificate should be considered

	37 // invalid.

	38 readonly attribute Date expires;
	philipj_slow 2015/10/08 08:32:31 I've filed a spec bug here: https://github.com/w3c I've filed a spec bug here: https://github.com/w3c/webrtc-pc/issues/324 The way it's implemented, I think this will return a new Date object every time. Can you verify if this is the case? hbos_chromium 2015/10/14 13:00:50 You're right, that's kind of blargh. cert.expires Show quoted text On 2015/10/08 08:32:31, philipj wrote: > I've filed a spec bug here: https://github.com/w3c/webrtc-pc/issues/324 > > The way it's implemented, I think this will return a new Date object every time. > Can you verify if this is the case? You're right, that's kind of blargh. cert.expires == cert.expires is false. philipj_slow 2015/10/16 13:32:31 Given that this is behind a flag I think this does Show quoted text On 2015/10/14 13:00:50, hbos_chromium wrote: > On 2015/10/08 08:32:31, philipj wrote: > > I've filed a spec bug here: https://github.com/w3c/webrtc-pc/issues/324 > > > > The way it's implemented, I think this will return a new Date object every > time. > > Can you verify if this is the case? > > You're right, that's kind of blargh. cert.expires == cert.expires is false. Given that this is behind a flag I think this does not need to be blocked, but if you just want to go ahead and rename it getExpirationDate() getExpiryDate() I will cheer you on to get the same change in the spec :) hbos_chromium 2015/10/19 15:21:35 The spec bug discussion has changed, right now it Show quoted text On 2015/10/16 13:32:31, philipj wrote: > On 2015/10/14 13:00:50, hbos_chromium wrote: > > On 2015/10/08 08:32:31, philipj wrote: > > > I've filed a spec bug here: https://github.com/w3c/webrtc-pc/issues/324 > > > > > > The way it's implemented, I think this will return a new Date object every > > time. > > > Can you verify if this is the case? > > > > You're right, that's kind of blargh. cert.expires == cert.expires is false. > > Given that this is behind a flag I think this does not need to be blocked, but > if you just want to go ahead and rename it getExpirationDate() getExpiryDate() I > will cheer you on to get the same change in the spec :) The spec bug discussion has changed, right now it looks like it will become "DOMTimeStamp expires". I added a TODO and created a bug that I'm referencing. When that discussion has settled I'll update expires accordingly.
33 };	39 };

34

OLD	NEW