RE: Proposed Charter Changes

I think I am agreeing with Justin here and I really don’t like some of the terminology being used regarding developing an “Object API”.  As a developer of WebRTC based applications what I believe is needed is some kind of roadmap to indicate what happens to the WebRTC API’s following the successful completion or at least stabilizing of WebRTC 1.0.

The terminology used below such as “Backwards-compatibility: applications which run in WebRTC 1.0 will continue to function with the Object API” only seems to enforce the idea that there will be two diverting Workstreams and API’s which is what I assume we want to avoid and it does not give developers any reassurance that what they are developing today will continue to work tomorrow without lots of reworking.

As Ekr stated “: sites which work now should workin a browser which implements the 1.1 API without *any* modification to those sites, including loading a JS polyfill [0].”.  I don’t think this means that we have to be stuck with maintaining the 1.0 API forever but I think it is reasonable to provide the community with a statement that backwards compatibility is maintained in the near term.  It also does not mean that new applications could not be written using entirely new API surfaces.

We are already moving in the direction of including elements of the ORTC API in to the WebRTC API’s so can we not find a way to describe the future roadmap as a continuation of this and a migration rather than a straight replacement with continued maintenance of two different API’s.

Andy



From: Justin Uberti [mailto:juberti@google.com]
Sent: 30 April 2015 22:39
To: Erik Lagerway
Cc: Cullen Jennings; Eric Rescorla; Bernard Aboba; Michael Champion (MS OPEN TECH); public-webrtc@w3.org
Subject: Re: Proposed Charter Changes

I agree that NG doesn't really explain what its purpose is, and "object" is similarly vague.

I think it needs the exact goal of this effort needs to be made explicit. I am not wedded to the term "low-level", but somehow the relationship between 1.0 and the new API needs to be described, as well as how the new API differs from the existing API. And to be clear, "does not use SDP" is not an adequate description; SDP does something, so are we inventing an alternative, or specifically leaving that functionality to applications (and thereby moving down a layer in the stack?)

I will take a shot at coming up with text for this.

On Thu, Apr 30, 2015 at 1:55 PM, Erik Lagerway <erik@hookflash.com<mailto:erik@hookflash.com>> wrote:
The bulk of the changes are as follows, template from Dom, some from Ekr, some from Tim, some from me + removed the Liaison requirement.

As 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 working on a new set of object-oriented APIs for real-time communication to produce an object-oriented specification to follow 1.0. The activities in the ORTC (Object Real-time Communications) Community Group indicate that there is interest in a new set of APIs. As part of this consideration, the group will reevaluate its deliverables and milestones, and may reconsider its scope.

In developing an Object API, the WG will adhere to the following principles.
- Backwards-compatibility: applications which run in WebRTC 1.0 will continue to function with the Object API.
- Standalone operation: The new Object APIs will be sufficiently complete as to prevent the need for the programmer to switch between object-orientated and 1.0 SDP styles in order to complete common tasks.
- Feature independence: New features may be introduced in the object-oriented API that are not accessible in the documented 1.0 API or that are only added to the 1.0 SDP API in future versions.

The WG will make efforts to align on API methodologies and nomenclature with the ORCT CG when contemplating design of similar APIs in the WG. This may include scheduled design meetings with relevant WG and CG stakeholders to foster further convergence of the APIs.

---

Your comments around "Object" are noted, also heard that "low-level" and "NG" are not working for some as well, so not sure what to do there.



/Erik

On Thu, Apr 30, 2015 at 11:21 AM, Justin Uberti <juberti@google.com<mailto:juberti@google.com>> wrote:
Can you put up a link to a github diff? It's hard to tell which parts are new here.

I am not a fan of the "Object" / "1.0 SDP" terminology. Most of the objects already exist (or will exist) in 1.0, so calling the NG thing "Object" seems inaccurate at best.

On Thu, Apr 30, 2015 at 9:59 AM, Cullen Jennings <fluffy@iii.ca<mailto:fluffy@iii.ca>> wrote:

I look forward to seeing the discussion on the Hookflash proposal and I need to think about about it more but my first reaction is that looks like something that I could live with and might be OK to most the WG.


> On Apr 30, 2015, at 10:02 AM, Erik Lagerway <erik@hookflash.com<mailto:erik@hookflash.com>> wrote:
>
> Based on concerns raised and after speaking to several WG and CG participants, I am proposing the following changes:
>
> - removed liaison requirement
> - added some copy around getting the groups working together
> - changed "low-level" to Object
> - changed "high-level" to 1.0 SDP
>
> I believe this addresses most of the concerns and feels like a common ground we can start from, the proposal in its entirety is attached.
>
> Cheers,
> Erik
>