Re: Forward compatibility and SDP APIs

I appear to be late to the party (I didn't even realize this list existed
until yesterday).  But, what is SBC.js?

And, by the way, what is this list trying to accomplish?  Have I missed
anything good?


On Wed, Sep 4, 2013 at 3:02 PM, Martin Thomson <martin.thomson@skype.net>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.
>
>