- From: Eric Rescorla <ekr@rtfm.com>
- Date: Thu, 19 Dec 2013 11:00:37 -0500
- To: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
- Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
On Thu, Dec 19, 2013 at 6:10 AM, Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> wrote: > Hi all, > > we've now gone through the list of items that could be in/out of 1.0 of > WebRTC, and developed our opinion. > > Clue for reading (most should be obvious): when there is a strange name > in the "Can be own spec?" column we propose creating a separate document > (with that working name). > > Sorry for the very short notice, we'll talk more about this at the > telechat in a little less than five hours. I've gone through this list and it makes me pretty sad; this seems like a recipe for a system which is primarily useful for demos, but not suitable for building the range of applications that people really expect. As a worked example of this, let's start by considering track rejection and hold. If I am on a low bandwidth link and someone offers me video, I need to be able to reject it; it's not enough to just not display the video, since it's still chewing up bandwidth. So, this seems like a fairly critical feature for a minimally functional system, and yet the chair's proposal is to defer past 1.0. How can this work? After that, rather than go through this list--which is rife with this kind of stuff--line-by-line, we need to figure out how to look at this at a higher level in terms of what functionality we actually need. This list seems to assume that the standard is "could you build anything at all and then retrofit the real functionality you need later." I strongly disagree with that. -Ekr
Received on Thursday, 19 December 2013 16:01:50 UTC