- From: tim panton <thp@westhawk.co.uk>
- Date: Sun, 5 Apr 2015 11:41:51 +0100
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- Cc: "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, Justin Uberti <juberti@google.com>, Erik Lagerway <erik@hookflash.com>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>
I think we need to be _very_ clear about what we mean by ‘compatibility’ - I think it is reasonable to expect that future post 1.0 releases of the webRTC standard(s) should be compatible with 1.0 . For me that means : 1) The wire format is fully compatible -> 1.0 and 1.1 browsers and devices can exchange media and data channels with no gateways. This is largely an IETF matter, but the W3C should avoid doing anything that precludes it. 2) Web apps written to the 1.0 standard should work in 1.1 implementations. (if we went to 2.0 that expectation might be relaxed somewhat). However…. I don’t expect this to apply to apps which have manipulated the SDP directly (as described by Chris Wendt <chris-w3c@chriswendt.net> > We’ve had to essentially hack the system with the current SDP exchange in many respects and at a minimum pass a bunch of redundant information. ) I think it is reasonable to expect javascript programmers to add dynamic polyfill here if it detects that the browser implements a new version of the standard and use that pollyfill to tweak bandwidths or mark which track is from a screenshare (for example). So I expect that 1.1 (and to a lesser extent 2.0) would implement all the javascript object/methods/properties and callbacks specified in 1.0 - but I don’t expect the content of the supposedly 'opaque blobs’ to backwards compatible. In some ways this is regrettable - since almost all of my webRTC apps to date have had to mess with the SDP, but I’m still hoping that as we get to 1.0 the need for this will be reduced. Having spent the last month working with web devs and watching their first exposure to the ‘joys’ of SDP I think that for webRTC to be a popular API, we may need to remove SDP as an API mechanism so we should not make charter decisions now that preclude that future choice. Tim.
Received on Sunday, 5 April 2015 10:42:24 UTC