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

Re: Capture API question

From: Robin Berjon <robin@robineko.com>
Date: Wed, 16 Jun 2010 11:50:30 +0200
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis@w3.org
Message-Id: <4D82FFC5-53F7-40E4-892B-35063B8A8D20@robineko.com>
To: Andrei Popescu <andreip@google.com>
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.

> True, but I don't see it as a roadblock: I think it's possible for
> most UAs to detect the installed input sources and present the user
> with a selection dialog that has a natural look&feel for the user's
> OS.

Agreed, I mostly bring this up because it's feedback I'd received from talking to Mozilla previously. I look forward to seeing solutions sprout up.

>> If developers and implementers are happy with an approach even simpler than the one we currently have, I (personally) would be happy to specify just that. We can separately write a "Trusted Capture" specification for non-Web environments that builds atop it.
> 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.

> For now, it seems like MediaFile is pretty much what we need. We were
> thinking of adding an 'encoding' parameter (e.g. following rfc4281),
> would that make sense to you?

It makes sense to me, what do others think?

Robin Berjon
  robineko  hired gun, higher standards
Received on Wednesday, 16 June 2010 09:51:02 UTC

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