- From: Cullen Jennings (fluffy) <fluffy@cisco.com>
- Date: Wed, 8 Apr 2015 12:26:44 +0000
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
- CC: Peter Thatcher <pthatcher@google.com>, Justin Uberti <juberti@google.com>, Göran Eriksson AP <goran.ap.eriksson@ericsson.com>, "Michael Champion (MS OPEN TECH)" <Michael.Champion@microsoft.com>, "Erik Lagerway" <erik@hookflash.com>
I updated my proposal with Peter's text. The latest version is at https://github.com/fluffy/webrtc-charter/blob/fluffy/proposed-charter.txt > On Apr 8, 2015, at 2:19 AM, Göran Eriksson AP <goran.ap.eriksson@ericsson.com> wrote: > > > > >> I'm also just a simple engineer, unclear on what has to go in a charter >> and what doesn't. But it sounds to me like we're all trying to decide >> on and agree upon what "1.1" and "compatibility" >> mean right now, even though we could just as easily decide that later. >> Could we simply change the charter text to the this? >> > > That feels like a good, practical approach right now. Focus on getting 1.0 > done. Personally I hope we will also see focus on testing soon in the WG, > including nailing down the protocol parts done as well, i.e the relevant > IETF drafts to LC. > > Again, +1 to Peters proposal. > > >> >> >> >> On Fri, Apr 3, 2015 at 5:41 PM, Justin Uberti >> <juberti@google.com> wrote: >> >> I am just a simple engineer, so these process issues frighten and confuse >> me. Nevertheless, I've tried to respond to the concerns you raised below: >> >> On Thu, Apr 2, 2015 at 8:49 PM, Michael Champion (MS OPEN TECH) >> <Michael.Champion@microsoft.com> wrote: >> >> Iıve seen Cullenıs counterproposal [1] to Domıs proposed charter >> revision [2] that addressed comments on the charter balloted by the AC. >> As Microsoftıs Advisory Committee representative who filed one of those >> comments, I see two fairly fundamental issues here. >> >> First, we strongly believe the WebRTC WG should focus on getting WebRTC >> 1.0 done as soon as possible, and that work shouldnıt be distracted by >> discussions about a next-generation standard. Contrary to some >> assertions expressed on this list, Microsoft and >> Hookflash do want to see a WebRTC 1.0 Recommendation completed that >> reflects the WG consensus to integrate an object model, along the lines >> proposed by Justin Uberti. Also, having a basic object framework within >> WebRTC 1.0 (even if the objects are not used >> for direct control) is an important step toward future work. Until the >> WebRTC 1.0 standard is completed, it is premature to talk about >> interoperability between WebRTC 1.0 and some future standard. >> >> >> >> >> I don't entirely get the concern about compatibility. For the benefit of >> developers using WebRTC, wouldn't we want to ensure this? >> >> >> Second, we see a major distinction between chartering the WEBRTC WG to >> ³extend² the WebRTC 1.0 API, while retaining the SDP control mechanism, >> and working on an API that does not utilize SDP. In our view, a WebRTC >> 1.0 API with objects only has limited opportunities >> for extension within the object model, since the objects could only be >> used to provide functionality that is not negotiated. As a result, we >> view the former approach as more of a ³WebRTC 1.0 maintenance² exercise. >> ORTCıs goal has been to support the WebRTC >> 1.0 feature set without SDP, which we view as an approach better able >> to accommodate advanced video in the short term and significant >> additional functionality in the long term. While we recognize there are >> different views on the way forward, we donıt think >> constraining future specs to be backward compatible with 1.0 is a good >> idea, certainly not at this point when the 1.0 spec is still immature and >> interoperability between independent implementations of 1.0 has not been >> rigorously demonstrated. >> >> >> >> >> The path we have been on (IIUC) is that if you program to the high level >> API (e.g. PeerConnection), you don't get to set all the knobs at the low >> level. If you program directly to the low level objects (e.g. >> RtpSender/RtpReceiver/Transport/etc), you get >> full control, but you're on your own for signaling. >> >> >> I don't see any problem with calling this "extending 1.0", and this seems >> like the best path for everyone involved - it is good for developers and >> easy to explain. Do you have some alternate future scenario in mind that >> you want to allow for? >> >> >> >> >> >> >> >> >> > > >
Received on Wednesday, 8 April 2015 12:27:01 UTC