Forward compatibility and SDP APIs

(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 Wednesday, 4 September 2013 22:04:03 UTC