Re: Proposed Charter Changes

On 02/04/15 00:55, "Cullen Jennings (fluffy)" <fluffy@cisco.com> wrote:

>
>> On Apr 1, 2015, at 4:29 PM, Eric Rescorla <ekr@rtfm.com> wrote:
>> 
>> 
>> 
>> On Wed, Apr 1, 2015 at 2:29 PM, Göran Eriksson AP
>><goran.ap.eriksson@ericsson.com> wrote:
>> Hi,
>> 
>> Just a few questions to ensure I don¹t misunderstand:
>> 
>> >
>> >s the name implies, WebRTC 1.0: Real-time Communication Between
>>Browsers
>> >is to be considered as a first version of APIs for real-time
>> >communication. The working group will, once WebRTC 1.0: Real-time
>> >Communication Between Browsers reaches Candidate Recommendation,
>>consider
>> >proposals for backward-compatible object-oriented extensions to this
>>API.
>> 
>> I assume ³backward-compatible² include the possibility of the 1.0 API
>> being supported using a js-shim on the evolved object-oriented/inspired
>> low-level API's?
>> 
>> The word ³extension²; does that mean new functionality ³only² could be
>> object-oriented or does it also allow for existing functionality in 1.0
>>to
>> be supported with low-level oo- API's, replacing 1.0 approach API's,
>>were
>> the WG to consider that motivated and desirable?
>> 
>> 
>> 
>> I interpret this as requiring that implementations written to the 1.0
>>API
>> function with the 1.1 API. If implementations want to internally do
>>just OO
>> APIs and have a JSL, that's their business.
>> 
>> Cullen, is that what you meant?
>> 
>> -Ekr
>> 
>> 
>
>Yes - exactly. 
>
>I think of it as if I have a website that works with version X of the
>browser that only has the 1.0 API, that same website keeps working when a
>user uses version X+1 of the browser that has the 1.1 API. How the
>browser makes that happen and how they decide to split up their
>implementation is no worry of mine. I realize some browsers use various
>JS polyfills to make stuff happen.

Words are important,:-)! Yes, that browser UA’s use JS to implement API’s
are not uncommon. Another way of supporting backward compatibility with
JS-shim/polyfill/etc would be to have it shipped with the web app meaning
the web site would have to change, but I understand that this option would
be blocked for the WG. And supporting backward compatibility to Web
1.0-enabled site (though not that many) is relevant.

However, then the meaning of “extension” is even more important since that
also could be interpreted as new low-level APIs *only* for new
functionality and not to do what 1.0 does, e.g. in a slightly different
way.

It gives me the impression that this puts quite some constraints on the
evolution of WebRTC API’s and constraints written in stone (charter)- a
WebRTC 2.0 API would have to include the 1.0-API’s also for sites designed
for 2.0. 

Is that a correct interpretation?


Best Regards
Göran


> 
>
>
>
>

Received on Thursday, 2 April 2015 09:12:26 UTC