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

Re: CfC: The Media Capture API FPWD

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Thu, 02 Sep 2010 10:25:12 +0200
To: public-device-apis@w3.org
Message-ID: <1283415912.20647.2550.camel@localhost>
Le mercredi 01 septembre 2010 à 21:37 +0200, Frederick.Hirsch@nokia.com
a écrit :
> This is a call for consensus to see if there are any objections to publishing the Media Capture API as a FPWD.
> 
> The draft can be read at:
> http://dev.w3.org/2009/dap/camera/Overview-API.html

+1 on publishing it. Given its dependency on some of the changes that
were brought to the html-media-capture editors draft, I would suggest
publishing along a new version of that document as well.

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;

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

• 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

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

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

• 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

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

• 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

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

Dom
Received on Thursday, 2 September 2010 08:25:20 GMT

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