W3C home > Mailing lists > Public > public-device-apis@w3.org > September 2010

Re: CfC: The Media Capture API FPWD

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Fri, 03 Sep 2010 15:58:28 +0300
Message-ID: <4C80F0F4.5020807@nokia.com>
To: ext Dominique Hazael-Massieux <dom@w3.org>
CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Hi Dom,

02/09/2010 11:25, ext Dominique Hazael-Massieux kirjoitti:
> 
> A few comments that can be addressed before or after publication
> (I've already made mostly editorial modifications directly in the
> text) since I don't think they affect the scope of the document: •
> the example in the intro refers to "err.message" but there is no 
> message attribute in the CaptureError interface;
> 

This is now corrected.

> • the privacy and security section talks about "authenticated" 
> operations — I think this should talk about obtaining user consent 
> instead

I agree, corrected.

> 
> • there is a "MUST" in a note in that same section; if we really mean
> it as a MUST (of which I'm not entirely convinced), the said text
> should be outside of the NOTE
> 

I removed normative language from the note.

> • 3.1 reads "Objects implementing the NavigatorDevice interface … 
> provide access to the Capture interface through the Capture
> interface"; there is no reference to what NavigatorDevice is; and
> providing "access to the Capture interface through the Capture
> interface" doesn't make sense
> 
> • I don't understand "An instance of Capture would be then obtained
> by using binding-specific casting methods on an instance of 
> NavigatorDevice."
> 

I'm not sure either. Maybe other editors know better.

> • given that supported*Formats is directly under navigator.device, I 
> wonder if we're not creating ambiguity in what "supported" means (it 
> could be "supported" for viewing vs creating vs streaming, etc)
> 

One way to solve this is to move Capture API under
navigator.device.capture. Capture would be then in line with the
three-level namings in Contacts, Calendar, and Messagaging. Any
objections?

> • I don't think the algorithms for the capture*() methods should
> talk about "native audio recorder/camera application"; after all, we
> have no reason to forbid browsers to start their own thing, possibly
> integrated in the browser viewport if they feel like it; we should
> probably mention the possibility of using an external app, but not
> mandate it
> 

I agree, text is too restrictive. Updated.

> • is it an error condition when the recording application exits
> without any mediafile (e.g. the user chose not to send any file
> eventually)? or does it trigger a success callback with an empty
> array? this might be what "the user exited the application
> prematurely" refers to, but that's not very clear (to me at least)
> 

This is now clarified.

> • the algorithms for captureVideo and captureAudio should also
> reference the duration parameter (in addition to
> maxNumberOfMediaFiles)
> 
> • maxNumberOfMediaFiles is very long; I hope we can find a better
> name
> 

My proposal is 'limit'

> • how do you allow a user to take as many pictures as she wants? as
> long video/audio as she wants? in other words, how should infinity
> be represented for maxNumberOfMediaFiles and duration? What happens
> when they're set to 0? a negative number for duration?
> 

I have assumed that if no value has assigned to maxNumberOfMediaFiles
then it means no limit. Zero and negative numbers needs to be forbidden.

         -ilkka
Received on Friday, 3 September 2010 12:59:22 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:12 GMT