Re: Cisco's position on the WebRTC API

On Tue, Jul 23, 2013 at 8:05 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:

>  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.
>

Sorry, this was my bad. As I mentioned to Sylvia, this was a typo.



>  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.
>

Yes, I think this is an accurate reflection of the general view of the WG.


  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.
>

Both Firefox and Chrome are moving away from the use of any kind of prefix
in their APIs:

http://www.chromium.org/blink#vendor-prefixes
https://groups.google.com/forum/#!msg/mozilla.dev.platform/itl6mtx2dxI/mbdPvbexB2EJ



>
>>    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 don't think that this is really reasonable. SDP is incredibly flexible
and there are
parts of it we wish people wouldn't use. I do think that any feature that
someone
can present a credible use case for should be seriously considered for some
sort
of non-SDP API point.





>      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.
>

We're mostly not adding stuff to SDP. Most of the things people have been
discussing adding API points reflect existing SDP functionality.

 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.
>

Frankly, I think it's statements like this from you that people are
reacting negatively to.
First, we're not talking about me. Second, you in fact have repeatedly
complained
that other people aren't responding to you. Indeed upthread you complain
that
Cullen didn't back you on the list.



>      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.
>

Again, I think the WG has been fairly transparent about its plans.

>
>     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 :)
>

Yes. I was on that call. Needless to say, I don't think Alex's writeup is
at all unbiased
as to what happened. It's particularly odd to see a complaint about "the
little guy"
given that the two major proponents of Futures were from Mozilla and Google
(as were most of the major opponents). Indeed, Alex himself works for
Google.

-Ekr