W3C home > Mailing lists > Public > public-media-capture@w3.org > February 2013

Re: Image Capture Proposal

From: Adam Bergkvist <adam.bergkvist@ericsson.com>
Date: Tue, 19 Feb 2013 14:30:29 +0100
Message-ID: <51237E75.1030807@ericsson.com>
To: "Mandyam, Giridhar" <mandyam@quicinc.com>
CC: "public-media-capture@w3.org" <public-media-capture@w3.org>

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.



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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:26:15 UTC