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

Re: Capture API question

From: Andrei Popescu <andreip@google.com>
Date: Fri, 11 Jun 2010 11:21:00 +0100
Message-ID: <AANLkTimkBOMOiiqrL8dLo3I7Vu7vEkWw3Ud4uinm0Gns@mail.gmail.com>
To: Dominique Hazael-Massieux <dom@w3.org>
Cc: public-device-apis@w3.org
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.

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

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.

Received on Friday, 11 June 2010 10:21:30 UTC

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