Re: Capture API question

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*