Re: Cisco's position on the WebRTC API

On 23/07/2013 10:00 PM, Eric Rescorla wrote:
>     My understanding was: "Our goal is to map all use-cases to 
> Constraints so that you never have to deal with SDP, unless you want 
> to play with experimental features (outside the scope of the 
> specification) and the expectation is that even those will eventually 
> make their way into the Constraints API."
>
> I don't see the difference between that and what I just said.

     The difference lies in the following sentence you wrote:

> - To the extent to which there are meaningful use cases that the API 
> doesn't
>   deal with, we want to eventually add features to the SDP to deal 
> with that.

     Specifically, you seem to be using the word "SDP" and "API" 
interchangeably. To me, the Constraints API is the API. SDP is an 
implementation detail. I agree with your sentence if you replace the 
word "SDP" with "Constraints API". In other words, initially 
experimental use-cases are only accessible via parsing/mutating the SDP 
by hand and eventually they get added to the Constraints API so users 
don't have to touch the SDP.


>
>     In other words, I understood that SDP is the logical equivalent of
>     CSS prefixes.
>
>
> I don't know what that means.

     I meant that when a specific browser introduces some experimental 
feature, it should expose a "prefixed" Constraints key. For example:

".webkit-transform" is the Webkit-specific implementation of what later 
became CSS3 "transform"

     In the case of WebRTC, you could do the following:

var videoConstraints =
{
   "mandatory":
   {
     "minWidth": 1024,
     "-chrome-aspectRatio": 16/10
   }
};

     and eventually replace this by "aspectRatio" when the property is 
standardized.

>      1. I'm fine with his answer. Ideally I'd like the API to hide SDP
>         under the hood and tunnel experimental features through
>         Constraint prefixes (similar to CSS prefixes) but I'll accept
>         the status quo if this is the best we can do.
>      2. Yes, I wanted him to affirm what he said publicly because I've
>         read contradictory assertions on the mailing list.
>
> What contradictory assertions do you think people have made? I think 
> both Stefan and I
> have said that we believe that the bullet points above are more or 
> less the position
> of the WG. If you think people are taking a different position, then 
> please point
> to the relevant WG messages.

     The commitment I am looking for is that all common use-cases that 
are already exposed by the SDP be exposed by way of the Constraints API. 
I am not asking you to add new SDP keys for new use-cases... but if a 
feature is already accessible through SDP then I expect you to provide a 
corresponding Constraints API for it. And I am asking for 1.0 to hold 
off until this is done.

     I understand that you want to ship 1.0 within 6 months, and you can 
still do so. You can limit the scope of the Constraints API by virtue of 
limiting what you add into SDP.

> With that said, I think you have an unrealistic expectation about the 
> degree
> to which individual WG participants are obligated to respond to you.

     Eric, you're not obliged to do anything. The community will judge 
you by your actions, or lack thereof.

     Again, I have no wish to argue with you. In fact the opposite. I 
believe that a lot of the arguments on the list could have been avoided 
if the Working Group would have been transparent about its plans.

>         Look, essentially we have a problem of trust. I am looking for
>     the Working Group to make a public/binding commitments for major
>     decisions. This doesn't mean that they can't change their mind at
>     a later time, but at the very least they will need to explain
>     themselves and the community will judge if their reasons are
>     reasonable.
>
> I don't understand what this means. Text gets written and discussed and
> either has consensus or it doesn't. If there are big controversial topics
> they get discussed and minuted. I don't really understand what you think
> would constitute a binding commitment other than that.

     Part of the problem is the segregation between rtcweb and 
public-webrtc. Many of these proposals are happening on rtcweb and the 
folks on this list never see or hear about them. Normally this wouldn't 
be a problem, except the current API has the unfortunate side-effect 
(flaw) of implementation details (discussed on rtcweb) affecting API 
design (discussed on webrtc-public). Most project-wide discussions are 
not cross-posted to this list which again leaves these folks out of touch.

     The only time I attended an IRC meeting (the only one announced on 
this list in over 2 months), we discussed whether to use DOM Futures in 
the API. That meeting went ... a bit sideways: 
http://lists.w3.org/Archives/Public/www-tag/2013Jun/0011.html

     Alex wrote: "I don't think it's stretching the case to say that the 
reception was something close to hostile, if not outright incredulous." 
Frankly, that's the kind of feeling I got from the discussions on this 
list over the past 2 months. These "discussions" aren't really 
discussions. These "meetings" aren't really meetings. It feels like 
companies with political agendas entering the room and jumping the 
little guy. I haven't experienced this kind of behavior elsewhere. I am 
expecting/hoping for people to enter meetings with an open mind, looking 
for a compromise. What's with all the hostility? We're not out to eat 
your lunch :)

     So, on a more constructive note:

  * Please cross-post more project-wide agendas/schedules/decisions to
    this list if they affect the API (many of them do)
  * Please conduct more online API meetings (we'd like to attend them)
    and announce them on this list.
  * When developers bring up legitimate concerns, let's look for a
    compromise that is mutually beneficial to everyone. This isn't a
    zero-sum game.

Gili