RE: Image Capture Proposal

I think we either start a new unique document for it, or we add it as a new unique section to the recording API spec, slightly stretching its scope. I think I prefer the latter option since I envision the recording and image capture proposals to move to Rec at roughly the same pace (e.g., implementations would probably want to implement them both at the same time?)

> -----Original Message-----
> From: Jim Barnett [mailto:Jim.Barnett@genesyslab.com]
> Sent: Tuesday, February 19, 2013 6:23 AM
> To: Stefan Håkansson LK; public-media-capture@w3.org
> Subject: 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 Wednesday, 20 February 2013 01:09:55 UTC