Re: Capture API question

On 6/11/10 3:21 AM, Andrei Popescu wrote:
> On Fri, Jun 11, 2010 at 10:48 AM, Dominique Hazael-Massieux<dom@w3.org>  wrote:
>    
>> Le vendredi 11 juin 2010 à 10:41 +0100, Andrei Popescu a écrit :
>>      
>>>> That said, we're very much interested in getting feedback — in
>>>> particular from implementors — on whether these additional features are
>>>> needed/useful in a v1, or if focusing on the form-based approach is more
>>>> cost-effective.
>>>>          
>>> On Android we are only implementing the form-based approach for now.
>>> This seems to work pretty well for the majority of the use cases we've
>>> encountered.
>>>        
>> Thanks, that's very useful to know; do you see a need for standardizing
>> anything addional about it, though? In other words:
>> * are you implementing or considering to implement the ViewFinder
>> interface, or are you only plugging access to the camera from the file
>> picker?
>>      
> No, we're not implementing the ViewFinder interface. We're just
> hooking the camera to the file picker. The only extension we're
> considering is to allow the author to invoke the camera directly using
>
> <input type="file" accept="image/*;source=camera">
>
> UAs that don't know what "source=camera" is will just pop up a regular
> file picker.
>    

This is the basis for implementation in Firefox.  We'll work with the 
existing form element.  We intend to use the File API for manipulating 
stills, just as we would a selection from the file system.  We'll use 
the same HTML syntax that Andrei mentions above, but haven't considered 
the additional "source=camera" bit.

1. Essentially take a look at: 
https://bugzilla.mozilla.org/show_bug.cgi?id=507749
2. We also intend to provide a path from Canvas to Blob: 
https://bugzilla.mozilla.org/show_bug.cgi?id=565843

The Capture API doesn't provide essential guidance for image capture on 
the web, and we are at present not considering it.  In particular, I 
find that:

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/


>> *are you implementing an additional set of methods on top of the File
>> API for media objects?
>>
>>      

I'd welcome discussion of a Camera API for the web, including 
integration with the DOM (Canvas, forms, etc.).

-- A*
> Not for now but we are considering exposing the properties of the
> captured media (e.g. dimensions, duration, encoding, etc) using a
> subtype of File, like MediaFile in your spec.
>
> Thanks,
> Andrei
>
>

Received on Friday, 11 June 2010 18:30:15 UTC