Re: Capture API question

Hi Andrei,

On Jun 16, 2010, at 12:35 , Andrei Popescu wrote:
> 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.

Fair enough, but please count my feedback now because I know that when I get around to using this, and cut and paste, which will happen, and change image to video but not camera to camcorder, which will happen, and waste several minutes staring at my code looking for bugs in all the wrong places, which will happen, I'll send you the very same feedback except with lots of extra expletives. So I think it's nicer for everyone if you just write it down now ;-)

>> 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.

Sorry if I was unclear. The form-based approach (which is great and goes a long way, don't get me) does use a permission dialog. It just so happens that it's a permission dialog that looks useful and gets the user to act (hopefully) smart by looking like something that's not a permission dialog.

> 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?

An external viewfinder, I don't think so, but a viewfinder (well, a live feed) from the camera, yes. A classic use case here is AR: if the user has to hit an input element to get the viewfinder, then agree to geo, then select contacts for facial recognition, then expose the local pictures to place them, etc. the app just doesn't fly.

This issue is described very cogently by Google's input to the Privacy Workshop (the papers aren't up on our side yet, but I'm sure you can get your hands on a copy in the meantime ;). There is a category of advanced web apps that just relies on too many features for user activation to be workable.

We don't need to get deep into that discussion here, I'm just trying to look at how exactly to slice up the levels. Here's a proposal that reflects previous discussion:

Level 1. Integration with HTML file input, perhaps addition of source MIME parameter (in discussion), MediaFile.
Level 2. Embedded ViewFinder.
Level 3. Whatever's left that people want to do.

I know we've been through this discussion a bunch of times, but any opinions from the list?

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

No one's talking about benefits of the current form over forms, only of the progressive layering of additional functionality on the latter.

--
Robin Berjon
  robineko — hired gun, higher standards
  http://robineko.com/

Received on Wednesday, 16 June 2010 11:30:07 UTC