Re: CfC: The Media Capture API FPWD

Hi Rich,

Thanks very much for your comments. My comments inline.

02/09/2010 01:22, ext Rich Tibbett wrote:
> 1. Perhaps we should have some consistency between ContactFindOptions
> and CaptureImageOptions, CaptureVideoOptions, CaptureAudioOptions?
> ContactFindOptions uses 'multiple' and 'limit' from the HTML File
> Input element while CaptureXOptions is using 
> 'maxNumberOfMediaFiles'.
> 

Maybe 'maxNumberOfMediaFiles' should simply be 'limit' with a good
description. Dom already noted that the current name is unnecessary long.
I'm fine using 'limit' everywhere.

> 2. Could CaptureVideoOptions and CaptureAudioOptions extend 
> CaptureImageOptions (with CaptureImageOptions being renamed to 
> CaptureOptions)?

I assume that CaptureImage options will include image specific options
like ISO sensitivy, shutter speed, and flash mode in the future and
thereby can't act as a base class for video and audio options.

> 
> 3. What is the correct result of 'supportedImageFormats', 
> 'supportedVideoFormats' and 'supportedAudioFormats'? The 
> 'MediaFileData' interface includes things like 'duration' which 
> probably don't make too much sense here. Either we could split 
> 'codec' from the full 'MediaFileData' or split 'duration' out for
> the reverse but equally workable case.
> 

I'd say width, height, and codec attributes make sense here. It's best
to keep HTML Capture spec as simple as possible. I'm therefore thinking
of creating a new more well suited interface at the API side with those
three attributes.

> 4. I never understood the difference between nullable and optional. 
> In Contacts everything that is optional is also nullable. I don't
> see why not (?)

I might be wrong but isn't the difference that JavaScript function calls
example(1, 2) and example(1) are legal and example(1, null) is not if the
second integer parameter is optional but not nullable. Is there then any
benefit to allow the null case?  I'm fine to align Capture API with
Contacts if it is more complex than this.

> 
> 5. How come we're using 'FileList' in the success callbacks? I 
> thought we had 'MediaList' in the HTML Media Capture API (for 
> multiple 'MediaFile' objects) but I've misplaced it in the latest 
> editor's draft.
> 

MediaFile interface has been removed as unnessessary from HTML Capture
specification [1]. Approach there is now that captured files are File
objects that additionally implement a second interface, MediaFile. I
believe we should follow the same logic here.

> 6. What happens if I have a pending callback and the user/page 
> initiates a second request to access media data? Is it queued, 
> cancelled pending completion of the first operation or something 
> else? Might be worth fleshing out the 'CaptureError' interface for 
> this and other potential error cases to be included.

Situations where the user tries to initiate multiple capture operations
at parallel are rare I think. It will be probably also uncommon that
scripts intitiate capture opeations on their own without waiting user
interaction. Therefore I propose just adding CAPTURE_DEVICE_BUSY error
code. Scripts can then decide what to do.

       -ilkka


[1] http://lists.w3.org/Archives/Public/public-device-apis/2010Jul/0118.html

Received on Thursday, 2 September 2010 12:39:05 UTC