Re: Image Capture Proposal

Hi

I think this looks good. Here are some comments.

> attribute MediaStream          stream;

I agree with previous comments that the ImageCapture object should 
operate on a track (to begin with).

>              attribute EventHandler         onphotoerror;
>              attribute EventHandler         onphotosettingschange;
>              attribute EventHandler         onphotosettingserror;

I think we could skip the "photo"-prefix on these event handlers names 
since it's given from the context.

> readonly attribute PhotoSettingsOptions photoSettingsOptions;

> interface PhotoSettingsOptions {
> ...
> };

Could we go with either "settings" or "options" in the name?

> ...then the UA must invoke the onphotosettingschange (if specified).
> ...then the UA must invoke the onphotosettingserror event handler (if specified).

An a few more places.

Should be: then the UA must fire a simple event named "settingschange" 
[with a <payload>] [at the <object>].

The event handler is then invoked as a consequence.

> interface PhotoEvent : Event {
>     readonly attribute Blob data;
> };

We should reference the more generic BlobEvent from the recording spec 
[1]. It does exactly what we need here.

> 6. PhotoSettingsOptions

Quite a large part of this proposal deals with settings. In [2] we 
talked about creating a "Constrainable" interface that would be 
implemented by, e.g., tracks and the recorder object that would deal 
with settings/constraints in a consistent manner. Perhaps that's 
something to consider here as well.

/Adam

[1] 
https://dvcs.w3.org/hg/dap/raw-file/default/media-stream-capture/MediaRecorder.html#blob-event

[2] 
http://lists.w3.org/Archives/Public/public-media-capture/2013Jan/0049.html

Received on Tuesday, 19 February 2013 13:31:01 UTC