Re: Capture API question

On 6/16/10 3:06 AM, Robin Berjon wrote:
> Hi Arun,
>
> On Jun 11, 2010, at 20:29 , Arun Ranganathan wrote:
>    
>> 1. The Capture API as currently written provides methods that we are not interested in implementing (at least for now), notably details about *how* images and video are captured.  It doesn't seem to build on existing mechanisms for dealing with form-selected data.  Also:
>> 2. The Capture API doesn't address integration with existing HTML elements.  It introduces an "unharnessed" API space, which I find troubling and cannot reconcile with how the web works.
>> http://blog.mozilla.com/standards/2009/12/30/web-standards-in-the-device-era/
>>      
> Well, the thing is that we've already decided to work in layers where we would have basic form-based integration to start with, and then going upwards additional details. However as we were thinking of how to best capture these changes we had a very good discussion with Mozilla during which it surfaced that you had interest in providing input on how you'd like the result to look like, so we decided to wait on that so as to avoid doing the work twice. That was two months ago.
>
> Now we can, should, and will move forward in refining this API with or without said input but I must say in full candour that I find it quite galling that you would come here brandying "trouble" and "unreconcilable" after we tried to engage with you and blocked waiting for your input.
>    

Firstly, I'm truly sorry if I've done anything galling, especially since 
I didn't mean to.  I'd like to restart this discussion so that galling 
words aren't brandied (!) :-)

http://dev.w3.org/2009/dap/camera/ is what I'm focusing on.  I like the 
Appendix B (User Interface Examples) and think that it is very good that 
the specification has such an appendix.

1. The camera is invoked through the Capture interface, which is 
implemented by NavigatorDevice.

navigator.device.captureImage(success,  error,  {  maxNumberOfMediaFiles:  1  });



This model is proposed alongside the input type="file" model with 
accept.  This is what I meant above when I referred to an "unharnessed" 
API space.  Some feedback on whether a NavigatorDevice interface was 
necessary at all was sent a while ago [1] (more than two months ago!), 
and then some feedback was sent by others [2] about the importance of 
tying into an element, noting Geolocation as an exception that may have 
been problematic.  I agree with that.  I don't think a 
navigator.device.* provides a useful invocation mechanism for camera APIs.

Dominque Hazael-Massieux [3] did some work looking at input element vs. 
API for the capture case, which I think is really useful.  If we support 
your "level" or "layer" approach, could we *first* focus input 
type="file", and then consider alternate approaches that address other 
use cases that DAP may have?  Just as you propose with File* APIs, this 
would allow DAP to address a use case that could be layered on top of 
the general (simple) web use case.

2. When the element is selected, the Capture API proposes a click event 
on trusted content.

document.getElementById('cameraInput').click()

We've already established differences of opinion with your definition of 
"trusted" and "untrusted" based on policy files.  Instead, we'd like 
that the UI itself is responsible for taking a photo, so that the flow 
follows a normal file selection, but with a camera icon as one option 
within file selection.  The API shouldn't expose 'click'; instead, let 
the user interact with the form control, determine to take a pic (or 
shoot a video), and then let the flow return to the File API.  Have I 
missed an important advantage of a programmatic click event here 
(trusted or no)?

We're working out issues with exposing native camera capabilities.  Some 
implementation links are:

https://bugzilla.mozilla.org/show_bug.cgi?id=507749
https://bugzilla.mozilla.org/show_bug.cgi?id=451674

3. The ViewFinder interface gives us methods to start and stop capture, 
and is supposed to be returned via the FileList (instead of File 
objects).  This gives start - stop control to the web developer.  The 
current Fx implementation allows the control to be given to the user 
during file selection. That way, you only interact with the taken photo 
by way of the File API, just as you would with any file.  Even the 
example in the spec allows web UI to toggle start and stop capture.  I 
think ViewFinder is useful, but not necessary here.  We should return a 
File object (MediaFile).

4. MediaFile and FormatData are both pretty useful, and we can return 
these for short videos and stills that the user takes as "enhanced" file 
objects.  I think these are good proposals.

Questions:

* Could we proceed with a web model that only looks at File API, 
MediaFile (and FormatData) as level 1 for capturing stills, short 
videos, and audios?  The level 1 specification should provide guidance 
on what the invocation syntax in HTML is for these input and capture 
devices.  We should discuss this in HTML5 via relevant public-html 
threads, if not already spawned.
* Could we flesh out use cases for ViewFinder and introduce it later?  I 
can see it as useful for other streaming use cases.
* There could be, as Robin proposes, an API for what he's called the 
"Trusted" scenarios (including installable apps).  It could layer 
gracefully on top of level 1 or so.

We don't have to block on completion of level 1.  I'd like to apologize 
if there was any blocking on feedback here; I'll chalk it up to 
communication errors.

-- A*

[1] http://lists.w3.org/Archives/Public/public-device-apis/2009Dec/0215.html
[2] http://lists.w3.org/Archives/Public/public-device-apis/2009Nov/0068.html
[3] http://www.w3.org/2009/dap/wiki/CaptureVsInput