W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: Spec question: Declaration of IceCandidate

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Tue, 19 Jun 2012 14:23:51 +0200
Message-ID: <1340108631.3163.56.camel@cumulustier>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
Le mardi 19 juin 2012 à 13:49 +0200, Harald Alvestrand a écrit :
> Simple object:
> foo = { x: ww, y: zz }
> InterfaceCall(foo)
> InterfaceCall has to check that x and y are present.
> Dedicated object:
> foo = new FooObject( { x: ww, y: zz } )
> InterfaceCall(foo)
> InterfaceCall has to check that foo is of type FooObject.
> Do I understand you correctly in what you mean by "using a javascript 
> object"?

Indeed. Note that using a dictionary (e.g. FooDict), we can get
verification of the presence of x and y for "free" in WebIDL. (that
said, I think in our case, the main matter is actually about checking
that x and y have valid values)

> If yes, and we have versions 1 and 2, 1 has Object as parameter, 2 has 
> FooObject:
> 1) version 1 is published
> 2) 10.000 programmers write code for it
> 3) version 2 is published
> Is version 2 backwards compatible, or do we have to declare that 
> InterfaceCall has a parameter of type "Object or FooObject" in order not 
> to break those 10.000 programmers' code?

We could make the type to be (FooDict or FooObject); or we could do a
method overload; or we could provide an interface in FooObject that
turns it into a FooDict (if we don't need to preserve the nature of
FooObject in that context).

> That's exactly the way we broke code in one of the many changes to 
> webkitPeerConnection (now deprecatedPeerConnection), I believe; once the 
> spec has 10.000 users, I'd like to not make that type of change any more.

I agree that once we have a widely deployed level 1 API, we can't afford
to make backwards incompatible changes; but it seems to me that the
forward compatibility story in these cases is fairly simple.

Received on Tuesday, 19 June 2012 12:24:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC