- From: Tobie Langel <tobie@fb.com>
- Date: Tue, 27 Nov 2012 20:28:39 +0000
- To: "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com>
- CC: "public-device-apis@w3.org" <public-device-apis@w3.org>
Thanks for your answers, Frederick. On 11/27/12 8:21 PM, "Frederick.Hirsch@nokia.com" <Frederick.Hirsch@nokia.com> wrote: >On Nov 21, 2012, at 7:38 AM, ext Tobie Langel wrote: > >> >> - The wording in the abstract seems to imply HTML Media Capture is only >> useful to immediately upload captured content. It might be worth >> mentioning it gives the document access to the capture content through >>the >> File API which allows client-side manipulation and storing (in >>IndexedDB). > >The primary purpose is to upload immediately captured content. Why not >use the FileAPI directly otherwise? How can the FileAPI launch capture control types? The use case is to take a picture, then manipulate and store it locally. >That said, we should not make changes which lose the primary purpose >though we could clarify that file upload is also possible > >> >> - I am not sure I fully understand the sentence "These form extensions >> enable the upload of still images, video, and audio directly from a >>device >> capture mechanism but capture the default offered by the device, >>providing >> limited control over what is captured." > >What is not clear? It says that using forms one can upload material >captured by device mechanisms but cannot have fine grained control like >handling tracks etc. It is unclear to me whether the limited control refers to that of the end user or the author. I'm also not sure what "the default offered by the device" means in that context. (Not trolling, I really don't understand. :-/ ) Thanks, --tobie
Received on Tuesday, 27 November 2012 20:29:18 UTC