Re: Capture API question

Hi Robin,

On Wed, Jun 16, 2010 at 10:50 AM, Robin Berjon <robin@robineko.com> wrote:
> Hi Andrei,
>
> On Jun 11, 2010, at 19:45 , Andrei Popescu wrote:
>> On Fri, Jun 11, 2010 at 3:51 PM, Robin Berjon <robin@robineko.com> wrote:
>>>  - image/*;source=camera
>>>  - video/*;source=camera
>>>  - audio/*;source=microphone
>>
>> Yep, except video should maybe use "source=camcorder".
>>
>>> Would it make sense to make it source=device for all three?
>>
>> Maybe, but I am not sure this saves us much typing while potentially
>> losing some clarity for Web authors.
>
> I'm not concerned with saving keyboard strokes, but more with silly bugs. The "source" parameter isn't a device selector, i.e. if there are two cameras on the terminal you can't go source=camera1 or source=camera2 (I presume that's the case, because otherwise you need a discovery mechanism to make it useful).
>
> So essentially all that you want to flag is the fact that the author indicated a preference for capturing from a device rather than from file. Syntactically, you only need one keyword for that, not three.
>
> This leads to bugs in that an author might copy code that brings up the microphone using audio/*;source=microphone, and just make half the change she needs to get a still instead: image/*;source=microphone or audio/*;source=camera.
>
> So it just seems like a hurdle to have three keywords to mean one thing, and to ask authors to specify their intent twice when one's enough. Not a huge deal, but these small details can make life simpler.
>

Yep, agreed it's a minor detail. It's true that copy&paste coding may
lead to bugs but those should not be that hard to detect. For now, I
think we'd like to try the more explicit values and listen to the web
developer feedback.

>>
>> That's good to hear, although is the separate JS API really that much
>> better / easier to use? I am thinking it is extra cost to developers
>> to learn and adopt a new API when they can achieve the same effect
>> using APIs they're already familiar with.
>
> The reason I bring up a separate "trusted" specification is to address the case of installable web apps that won't have to ask permission for just about everything (because as you know it doesn't scale) while not burdening the browser side with extra complexity. This requires an ability to enumerate sources and other such niceties that can be built on top.
>

I see. However, with the form-based approach, the permission is given
implicitly when the user taps the form control, so no permission
dialogs are required, either. Furthermore, the user still needs to
activate the viewfinder somehow and the <input> element provides a
suitable solution for that. Or are there use cases when the viewfinder
should be activated without any user interaction?

As for the ability to enumerate sources, that seems to be specified in
another API altogether:

http://dev.w3.org/2009/dap/system-info/#widl-InputDevicesAttributes-cameras

so I am still not sure what benefits the capture JS API, in its
current form, provides over the forms-based solution.


Thanks,
Andrei

Received on Wednesday, 16 June 2010 10:36:54 UTC