RE: Image Capture Proposal

I'd be happy to work on this interface.  Where would it go?

 - Jim

-----Original Message-----
From: Stefan Håkansson LK [mailto:stefan.lk.hakansson@ericsson.com] 
Sent: Tuesday, February 19, 2013 9:12 AM
To: public-media-capture@w3.org
Subject: Re: Image Capture Proposal

On 2013-02-19 15:02, Jim Barnett wrote:
> +1 for a general Constrainable partial interface that could be used here and in the recording draft.

I also think that would be very useful. Stefan

>
> - Jim
>
> -----Original Message-----
> From: Adam Bergkvist [mailto:adam.bergkvist@ericsson.com]
> Sent: Tuesday, February 19, 2013 8:30 AM
> To: Mandyam, Giridhar
> Cc: public-media-capture@w3.org
> Subject: 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 14:23:40 UTC