W3C home > Mailing lists > Public > public-media-capture-logs@w3.org > December 2016

Re: [mediacapture-image] Use the constrainable pattern instead of creating a subtly different function set

From: gmandyam via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Dec 2016 00:54:58 +0000
To: public-media-capture-logs@w3.org
Message-ID: <issue_comment.created-267204437-1481763297-sysbot+gh@w3.org>
@stefhak 

I did provide my view on applicability of constraints to ImageCapture 
in the discussion on 
https://github.com/w3c/mediacapture-image/issues/73.  In addition, I 
would note the following.  Apologies for any clumsy wording.

a) The contraints mechanism is already leveraged in ImageCapture, as 
the constructor 
(https://w3c.github.io/mediacapture-image/#ImageCaptureAPI)  uses a 
track to which constraints have been applied. 

b) That being said, constraints (in my opinion) add value when there 
is some form of contention.  By 'contention', I am describing a 
situation where for instance multiple tabs in the active browser 
context require media capture, each with their own individual 
requirements.  However, for ImageCapture this kind of contention is 
not applicable as the ImageCapture object is constructed using a track
 that has already been created based on the browser constraint 
resolution.

c) It is still unclear (to me at least) whether developers have fully 
understood the constraints concept in the context of MediaStreams and 
actually found value in using them.  In that respect, I am concerned 
about causing developer confusion by adding a 
constraints-on-top-of-constraints mechanism.  For instance, developers
 may ask why they cannot apply image capture constraints directly to 
the media stream itself.


-- 
GitHub Notification of comment by gmandyam
Please view or discuss this issue at 
https://github.com/w3c/mediacapture-image/issues/124#issuecomment-267204437
 using your GitHub account
Received on Thursday, 15 December 2016 00:55:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:27:30 UTC