- From: Kostiainen, Anssi <anssi.kostiainen@intel.com>
- Date: Thu, 19 Mar 2015 10:51:07 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, "Mandyam, Giridhar" <mandyam@quicinc.com>
- CC: "Hu, Ningxin" <ningxin.hu@intel.com>, "public-media-capture@w3.org" <public-media-capture@w3.org>
Hi Harald, Giri, > On 19 Mar 2015, at 10:46, Harald Alvestrand <harald@alvestrand.no> wrote: > > On 03/19/2015 09:30 AM, Kostiainen, Anssi wrote: [...] >> Harald, Giri - what was the reason for not reusing the MediaStreamTrack.getSettings() accessor? To my untrained eye it looks as if that'd allow us to drop the ImageCapture.photoCapabilities attribute that is specific to image capture, and reuse what MediaStreamTrack has to offer (I'm missing earlier discussions around mediacapture-image, so sorry if this has been discussed before). > > getSettings() is specific to the constraints model. Giri was of the opinion that he wanted a simpler model for settings manipulation than the constraints model used on MediaStreamTracks. What is the implementation status of the ConstrainablePattern [1]? Assuming the infrastructure is already in place, reusing it sounds like a reasonable path forward. Also, the mediacapture-main seems to encourage such reuse [2]: [[ The Constrainable pattern allows applications to inspect and adjust the properties of objects implementing it. It is broken out as a separate set of definitions so that it can be referred to by other specifications. ]] Unless there are technical reasons, I'd like to see whether we could make [1] work for the mediacapture-image, especially since I'm hearing no implementation has shipped yet. Giri - what are your latest thoughts on this? Thanks, -Anssi [1] http://w3c.github.io/mediacapture-main/#idl-def-ConstrainablePattern [2] http://w3c.github.io/mediacapture-main/#constrainable-interface
Received on Thursday, 19 March 2015 10:51:37 UTC