W3C home > Mailing lists > Public > public-media-capture@w3.org > October 2013

RE: Concluding initial list of constraints (was Proposal on initial list of constrains)

From: Mandyam, Giridhar <mandyam@quicinc.com>
Date: Tue, 29 Oct 2013 16:06:26 +0000
To: Harald Alvestrand <harald@alvestrand.no>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Message-ID: <CAC8DBE4E9704C41BCB290C2F3CC921A1663357A@nasanexd01h.na.qualcomm.com>
> We've actually been closing issues in an issue-by-issue fashion for the last 6 months. There's nothing surprising about asking for a specific issue to be closed.

Sorry, but you simply reposted a request from a group member without clarifying that the request was on behalf of the chairs for consensus from the group.  You should've been more clear.  

As I said, I will provide a full technical analysis of the constraints section.  This is not a "specific issue" in my opinion, as the note in Section 13 states in part:

" The following specific list(s) of constraints DOES NOT REFLECT CONSENSUS. Many constraints beyond these have been proposed, and the ones listed do not have universal support."

Note that 'constraints' is plural in the above note, and therefore corresponds to several issues - not just one.  

> Please state why you believe that these notes should not be removed.

Since you wanted a quick answer:

a) There was a straw poll of some sort at the February meeting, where votes were tallied on constraints.  According to the meeting minutes of the last TF F2F (http://lists.w3.org/Archives/Public/public-media-capture/2013Feb/0034.html), The results of the straw poll were only for the following constraints:  sourceID, width, height, aspectRatio, frameRate, facingMode, zoom, volume and gain.  There was no attempt to gauge consensus of the member companies about noAccess and peerIdentity, which have found their way into the spec.  There was no attempt to gauge objection to inclusion of these constraints by member companies.

b) Quite frankly, I do not understand how certain apps making use of hits API would use the peerIdentity constraint the way it is defined and I would like to see more discussion on this (for an example of such an app, see Example 2 in the specification).  At this point I would advocate for its removal.

The current definition of the constraint is " Prevent the stream from being applied to an element which is readable by the JS. Require that any PeerConnections to which the stream is added match the provided identity."  

For implementations that do not support WebRTC but will support Media Capture and Streams, it not clear why this constraint should be supported at all.  

c) It is certainly premature to include the noaccess constraint (why is this not camel cased like the other constraints?).  At this point, I cannot describe to my internal implementation team how to implement this constraint and how it relates to the permission UI.  There is clearly not consensus on the definition of this constraint based on my interpretation of the recent email discussion.  I would certainly object to the inclusion of a constraint with an unclear definition.

d) I would not object to the modification of the at least the note in Section 13 as follows:

" Note: Constraints listed below that are preceded with a '*' DO NOT REFLECT CONSENSUS. Many constraints beyond these have been proposed, and the ones listed that are not preceded with a '*' have the consensus of member companies."

Then rename PeerIdentity and noaccess accordingly as '*PeerIdentity' and '*noaccess'. 




-----Original Message-----
From: Harald Alvestrand [mailto:harald@alvestrand.no] 
Sent: Tuesday, October 29, 2013 8:20 AM
To: Mandyam, Giridhar; public-media-capture@w3.org
Subject: Re: Concluding initial list of constraints (was Proposal on initial list of constrains)

On 10/29/2013 04:01 PM, Mandyam, Giridhar wrote:
>> Please provide further justification for your position. The mere statement of disagreement is not a technical argument.
>> Sooner or later we have to specify which constraints are part of the spec. This seems to be a good time.
> Absolutely.  I was preparing this as part of an overall review of the latest spec, which I was intending to post to the mailing list prior to TPAC.  I apologize for my tardiness in getting this out to the group, but I did not realize that we were addressing the finalization of the spec in a section-by-section fashion.  I will get my comments on the constraints section itself out ASAP.

We've actually been closing issues in an issue-by-issue fashion for the last 6 months. There's nothing surprising about asking for a specific issue to be closed.

Please state why you believe that these notes should not be removed.
Received on Tuesday, 29 October 2013 16:06:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:20 UTC