Image Capture Proposal, fourth version

Hello All,
Thanks for all the feedback.  I am providing a new version (also available at http://gmandyam.github.io/image-capture/).  Please note the following:


a)      I am not ignoring the DOM Futures discussion in light of the interesting thread that resulted (see http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0008.html).  I do not however want to migrate this spec to using futures until the Task Force makes such a decision that encompasses all the specifications.  Related to Image Capture specifically, I am not seeing the use case that would leverage the interesting Future methods (e.g. .then()) in the context of the scenarios defined for this TF (see https://dvcs.w3.org/hg/dap/raw-file/tip/media-stream-capture/scenarios.html#take-a-picture) - I don't view migration to Futures as any sort of urgency.  For what it's worth, the W3C SysApps group has made the decision to migrate to DOM Futures now that it is part of the DOM living spec.


b)       I am also not ignoring the DOM Errors discussion either (see http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0158.html and http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0120.html, but it has been discussed several times earlier within the group).  However I would like to see a decision taken by the TF in order to keep consistency between all specs being developed, so I have not migrated to using DOM Errors/Exceptions yet.

Regarding specific feedback on the 3rd version:


a)      Travis's feedback (http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0034.html).

a.       Collapsed the error handlers somewhat so that there is only one onerror handler.  I believe the rest of the error event handlers can stay as is.

b.      Haven't updated the constructor to using VideoStreamTrack because this object hasn't made it into the latest Working Draft of the Media Streams and Capture spec, which I use as a reference (which is the reference that pops up for respec.js when [!GETUSERMEDIA] is used).

c.       I think by "individual state attributes .. . be put directly on the ImageCapture object" you meant something like the use of a readonly attribute for DOMError (see IndexedDB example - http://lists.w3.org/Archives/Public/public-media-capture/2013Apr/0182.html).  If the group comes to a common understanding about the use of DOMError then I will certainly adjust the spec accordingly.

d.      I am skeptical that this kind of object lends itself well to a constrainable interface.  My understanding is that constraints are applied in the creation of an object such as a MediaStreamTrack (how constraints are applied after the creation of a MediaStreamTrack seems to be an unsettled issue within the group).  The settings for the ImageCapture object are applied independent of the creation of any object; in fact the end user can change the camera settings without interacting with this API.  But I am open to any counter-arguments.



b)      roc's feedback (http://lists.w3.org/Archives/Public/public-media-capture/2013Mar/0118.html). I think I answered most of the feedback in the revision, so I will address what is unanswered.

a.       In general I could not conclude that error events will be propagated synchronously, so I have kept an onerror event handler.  We had concluded during the F2F in TPAC last November that camera settings should be applied ansynchronously (with e-mech zoom being the prime example, although zoom is covered in the creation of the MediaStreamTrack).  Moreover, since all error events will be propagated through one single hander in this latest revision, other errors which are asynchronously conveyed (e.g. when multiple takePhoto() calls executed consecutively) will also need to be properly handled.

b.      I am not against your suggestions on setting image height/width, but I want to see a common approach between the Recording API and this spec.  The current approach works in the sense that the implementation can match the selected image height/width to the nearest supported height/width pairs.  Whether or how to expose height/width pairs for recording or image capture is not something that the group has agreed upon.  Note that I proposed a mechanism (dictionary entry for VideoRecordingDimensionOptions) for Recording earlier:  http://lists.w3.org/Archives/Public/public-media-capture/2012Dec/0151.html.  It might be reusable (with a different name).

If I have missed any relevant feedback, I apologize.  Please bring it to my attention so that I can consider it.

-Giri