Re: New Editor's Draft of MediaStream Image Capture

On Sat, Oct 18, 2014 at 3:55 AM, Mandyam, Giridhar <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.