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

> • 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.

Received on Friday, 3 September 2010 12:59:22 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:45 UTC