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

Re: Capture API question

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 21 Jun 2010 11:51:24 -0700
Message-ID: <4C1FB4AC.6030307@mozilla.com>
To: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
CC: ext Dominique Hazael-Massieux <dom@w3.org>, "Tran, Dzung D" <dzung.d.tran@intel.com>, "Ingmar.Kliche" <Ingmar.Kliche@telekom.de>, Robin Berjon <robin@robineko.com>, Andrei Popescu <andreip@google.com>, "public-device-apis@w3.org" <public-device-apis@w3.org>, Brad Lassey <blassey@mozilla.com>, Doug Turner <dougt@mozilla.com>, "khuey@mozilla.com" <khuey@mozilla.com>
Greetings Ikka,

On 6/21/10 8:14 AM, Ilkka Oksanen wrote:
> On 18.06.10 11:14, ext Dominique Hazael-Massieux wrote:
>>  Le mercredi 16 juin 2010 à 17:38 -0700, Arun Ranganathan a écrit :
>> > 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.
>>  This sounds like a good plan to me, at least. Dzung, Ingmar, Ilkka,
>>  would one of you mind having a stab at re-formulating the Capture
>>  API into what Arun describes as Level 1 above? This would mean
>>  scraping 1.1, 3.1, 3.4 to 3.14, and massaging the remaining into a
>>  coherent set.
> I partially agree. ViewFinder interface was added to the API to
> address the feedback we received earlier. I have no problems removing
> it if there is now consensus that it can go to v2.

Can you point me to a reference to this feedback?  I'd like to learn 
more about the use cases behind ViewFinder.

I think FileList should only return a File objects, and not scriptable 
camera controls.  Right now, by having ViewFinder inherit from File (and 
thus, Blob as well) we have a scriptable object for camera controls and 
an asynchronously readable Blob with File metadata.  This doesn't seem 
right to me.

> I'm not still sure if it is reasonable to completely delete the
> programmatic way to initiate the capture process. Only two capture
> options exist currently but I expect that there will be need to add
> more soon. JavaScript API enables better extendability and I think
> therefore it should be part of the spec from the initial version.

I think programmatic ways to initiate the capture process can be added 
in a separate level; my recommendation is v2, but that v1 stays as 
simple as possible and as accurate as possible to current implementation 
plans in browsers, as evidenced by both Chrome and Firefox.

-- A*
Received on Monday, 21 June 2010 18:51:58 UTC

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