Re: Forward compatibility and SDP APIs

Thanks for raising the point so explicitly and thoroughly, Martin!

Yes, this has been an agreed and desired feature of the WebRTC platform 
for a couple of years now.
The particular formulation of it in the overview draft is using codecs 
as an example:

    3.  When a new codec is specified, and the SDP for the new codec is
        specified in the MMUSIC WG, no other standardization should be
        required for it to be possible to use that in the web browsers.
        Adding new codecs which might have new SDP parameters should not
        change the APIs between the browser and Javascript application.
        As soon as the browsers support the new codecs, old applications
        written before the codecs were specified should automatically be
        able to use the new codecs where appropriate with no changes to
        the JS applications.

If you wish to change this, I think you should go to the rtcweb mailing 
list - the orca list doesn't have that many readers yet, I think.


On 09/05/2013 12:02 AM, Martin Thomson wrote:
> (Another screed on the subject.)
>
> Harald Alvestrand made a comment at the tail end of the most recent WebRTC conference call that
> raised a red flag with me.  That comment was something to the effect:
>
>      "I want old applications to be able to take advantage of new features as they are introduced
>      [without changing any code]."
>
> This might sound like a great idea, but in practice it's a maintenance nightmare.  What if your
> application suddenly changed its behaviour because your operating system upgraded itself.  Would
> every change be for the better?
>
> Application compatibility is a big problem for operating systems, other platform software, and
> libraries.  This sort of statement trivializes it.
>
> Changing the behaviour of an existing application is usually permissible only as long as that
> behaviour still conforms to the original contract of the API.  Performance improvements usually fall
> within this category.  But there are often undocumented characteristics of an API that applications
> come to rely on.  Changing even undocumented behaviour is usually regarded as a breaking change to
> an API.  Because even if the contract was undocumented, the *actual* behaviour of an API forms a
> stronger contract than some specification.
>
> This is why versioning systems exist.  Regardless of whether changes are known to affect
> compatibility, they are typically rolled out along with a bump to the version number.  An
> application that cares about compatibility can remain on the old version.  Regardless of whether the
> old version is badly broken or not, the ability to use an older version of an API gives application
> maintainers time to sort out the changes, test them and update their code to accommodate the
> changes.
>
> ==The web platform
>
> Using an old version of the web platform is not really possible.  Modern browsers all automatically
> update.  For this reason, browser vendors are especially careful about maintaining backward
> compatibility, as well as all sorts of other compatibility.
>
> For the most part, new features on the web platform are easy to test for.
>
>      if (window.FeatureObjectOrFunction) {
>          // feature exists
>      }
>
> And, by and large, using the feature requires active interaction with the object.  That is, if you
> don't call the function or instantiate the object, then you don't need to worry about what it might
> do.
>
> ==WebRTC
>
> Now, Harald was talking about SDP.  I've made my views on the wisdom of this approach clear in the
> past, but this highlights the largest disconnect regarding the reasons.
>
> ==Undocumented, but contract nonetheless
>
> Let's say that WebRTC ships in your favourite browser.  Applications start using it.  As it stands,
> the exact form of SDP that a browser accepts (or does not accept) is largely undocumented
> [https://www.w3.org/Bugs/Public/show_bug.cgi?id=20810].  At some point, browsers will have to settle
> on something and stick to it.'
>
> Whatever happens, whether the API is documented or not, the implementation forms the contract.  It's
> going to be quite hard to change things.  Even if there are bugs, if those bugs turn out to be
> useful, it's going to be hard to remove them.
>
> ==Stealth features foisted on the unaware
>
> The biggest problem that SDP exposes is the ability for new features to be added and used without
> active application involvement.
>
> SDP is designed in a way that new features are negotiated.  Usually, new features are negotiated
> through the use of new attributes.  SDP implementations are required to ignore attributes (a= lines)
> they don't recognize.  Unsupported attributes are omitted from offers and answers, so that they get
> negotiated off.
>
> In WebRTC, that negotiation occurs between browsers.  Applications intermediate the SDP, so they do
> get a chance to meddle with the SDP that browsers generate.  But the expectation is that few will.
> Messing with SDP isn't for the faint of heart.  Even though we're seeing a lot of it already, it's
> usually fairly restricted.  Most applications probably won't completely scrub SDP in the same way
> that an SBC might.
>
> SDP provides is a channel that enables the deployment of new real-time features without application
> interaction.  For instance, the version of WebRTC currently deployed in Firefox (now 23.0) doesn't
> support BUNGLE.  At some later point in time, Firefox will offer and use BUNGLE by default.  Your
> application won't need to change to take advantage of this great feature.
>
> That is, unless you were depending on some characteristic of the BUNGLE-less implementation.  Maybe
> you were peeking at the SDP after the session resolves and requesting DiffServ markings for each of
> the separate flows by some box in the network.  Now that all the flows are BUNGLED, your markings no
> longer work properly because all the media is multiplexed onto the same flow.  And now, it's
> anyone's guess as to what is happening now that you are asking for two different markings on the
> same flow.  Firefox just screwed you without your permission.
>
> Now, this is hardly an issue right now.  WebRTC implementations are still behind private prefixes
> and no one expects anything like stability from APIs in that state.  Someday, that will no longer be
> true, and applications will be fully at the mercy of the browser vendors.
>
> I'm beginning to think that SBC.js will be worth a lot of money.
>

Received on Tuesday, 17 September 2013 08:59:08 UTC