RE: New Editor's Draft of MediaStream Image Capture

Ø  Generally I think we should only introduce additional objects and interfaces when there's some clear rationale for doing so, because all other things being equal, they add complexity.

Thanks.  I’ll bear that in mind for the next edit.


Ø  Aren't the possible MIME types returned exactly the same for both takePhoto() and grabFrame() --- any kind of still image format?

MIME types was misleading – my apologies.  takePhoto() should return compressed formats like JPG or GIF (Blob w/associated MIME type).  grabFrame() would return an ImageData() object.


Ø  Do we need to support the non-Promise API?

No.  I think we decided at the last face-to-face meeting that the Promise version was all that was required.  I am eliminating the listed event handlers in the next draft.


Ø  'zoom' should be 'double' or 'float', not 'unsigned long'.

OK.


Ø  I don't think 'onoptions' is needed. Most Web APIs don't have features like this.

I kept this in there because the photo settings could change due to end user intervention at any time (like on many  devices with integrated cameras).  The associated event would fire when this occurred.  setOptions() as a result is not a promise – the desired settings may not take effect if the end user overrules them.  Maybe the event handler should be called onsettings instead of onoptions.   I’m also fine with making setOptions() a promise, but the settings could change at any time independent of setOptions().  Allowing the developer to define an event handler would allow for the app to be notified when settings change due to any reason.

Note however that the developer can also poll the ImageCapture readonly attributes (e.g. ImageCapture.photoCapabilities) to see if the settings have changed and avoid listening for the event.  That did not seem to be very efficient to me.


Ø  Can you clarify somewhere which PhotoSettings are honoured by grabFrame()? Is the answer "none"?

My assumption is that all of the settings would be honored by both methods.  I can clarify in the text.

-Giri

From: rocallahan@gmail.com [mailto:rocallahan@gmail.com] On Behalf Of Robert O'Callahan
Sent: Sunday, October 19, 2014 8:14 PM
To: Mandyam, Giridhar
Cc: public-media-capture@w3.org
Subject: Re: New Editor's Draft of MediaStream Image Capture

On Sat, Oct 18, 2014 at 3:55 AM, Mandyam, Giridhar <mandyam@quicinc.com<mailto:mandyam@quicinc.com>> wrote:
Changing PhotoOptions to PhotoCapabilities is not a problem, and seems to make good sense.  Eliminating this object altogether in favor of individual readonly attributes is possible, but then I think the issue boils down to a matter of personal taste.  From my perspective as a spec editor, this is mainly an issue of readability of the spec as the desired functionality is retained with either approach.  However, you certainly have more insight than myself as to what would be the typical web developer preference for such a feature.  Would they prefer to have device capabilities accessible as a readonly object (PhotoCapabilities), or as individual readonly attributes?

Generally I think we should only introduce additional objects and interfaces when there's some clear rationale for doing so, because all other things being equal, they add complexity. I don't see such a rationale here. Spec readability issues are not very important, especially because you can easily organize the spec to group together the specs for a particular subset of attributes. ImageCapture is currently a small interface so moving PhotoSettings attributes into it will not bloat it to an unreasonable size. E.g. writing
  imageCapture.redEyeReduction = true;
  imageCapture.zoom = 1.5;
  image
  var promise = imageCapture.takePhoto();
looks reasonable to me.

  >  The difference between grabFrame and takePhoto is quite subtle. Would it make sense to only have one method and event handler, and add an option that specifies whether to just grab a frame or go to the effort of taking a still shot?

I was trying to avoid introducing unnecessary ambiguity, so two different methods were defined for the two possible photo capture events that could be raised by the capture device.   Depending on the method invoked by the developer, there is a clear understanding of the possible MIME types of the returned data.  It is possible to collapse this into a single method with an argument to set the option for capture – I am not sure what to call that method as takePhoto() may not be appropriate.

Aren't the possible MIME types returned exactly the same for both takePhoto() and grabFrame() --- any kind of still image format?

Additional feedback items:
-- Do we need to support the non-Promise API? I don't think we do. In that case the "onphoto", "onerror" and "onframe" handlers are not needed.
-- 'zoom' should be 'double' or 'float', not 'unsigned long'.
-- I don't think 'onoptions' is needed. Most Web APIs don't have features like this.
Can you clarify somewhere which PhotoSettings are honoured by grabFrame()? Is the answer "none"?

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo
otohoeo ofoioroeo ooofo ohoeololo.