Re: Forward compatibility and SDP APIs

I don't necessarily want to change it...for codecs. I worry more about the
generality implied in that original statement. BUNDLE still concerns me.

I'll take this up...when I finish my vacation and have time for more than
brief responses...and a more efficient keyboard than a phone keyboard.
On Sep 17, 2013 8:59 PM, "Harald Alvestrand" <harald@alvestrand.no> wrote:

> 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<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.
>>
>>
>
>