Re: Capture API question

On Wed, Jun 16, 2010 at 2:50 AM, Robin Berjon <robin@robineko.com> wrote:
> 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?

No, audio can come from either a webcam or the microphone, for example.

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

Just such a mechanism is approved in the changes to the System
Information draft I completed and were approved on the call today.  I
hope that implementers follow the robustness principle --
http://en.wikipedia.org/wiki/Robustness_principle -- and map a set of
at least a half dozen possible expected device names into synonyms
appropriate for the local environment (a phone's 'camcorder' is
essentially the same thing as a desktop 'webcam' for example) and then
try to obtain from alternate sources (if audio/* from a webcam, and
the system only has a microphone, try to use that instead.)

> The form-based approach 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.

Yes, "Record", "Stop", and "Submit" buttons for audio/*, or a
viewfinder, shutter button, and submit button for image/* are the sort
of implicit permissions which can be used instead of permissions
prompts.  But are there some cases where we would want, e.g., contact
database information to only travel over HTTPS instead of HTTP when
the form is submitted?  I don't know whether we've been addressing
those kinds of privacy requirements very well.

>> Furthermore, the user still needs to
>> activate the viewfinder somehow and the <input> element provides a
>> suitable solution for that.
>
> 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.

What is AR?  If someone is requesting an image/* or video/* then a
viewfinder (adjacent to either a shutter or record/stop/play buttons,
respectively) is usually going to be a pretty good idea for how to
render the form's input type=file accept=... element.  Maybe clicking
on such a viewfinder should make it full-screen for detail work.

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

I've been in this discussion since at least as far back as 1998, and
I'm glad to see the mime/type;source=device idea get agreed to by two
browser vendors.  I prefer http://www.w3.org/TR/device-upload in
theory, but actual implementations in practice.  In a perfect world,
the robustness principle would cause both <input type=file
accept="mime/type;source=name"> with mime type parameters to work the
same as <input type=file accept="mime/type" device="name">.  Should
both be recommended?

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

Real-time device input uploads allow teleconferencing applications as
well as online multiplayer role playing games such as
http://8dworld.com uses with microphones to teach English
pronunciation.  Forms will not work for real-time teleconferences or
games.

On Wed, Jun 16, 2010 at 3:06 AM, Thomas Roessler <tlr@w3.org> wrote:
>
> Another consideration: accept is currently specified in terms of a comma-separated
> list of MIME types without parameters.

In various standards, both commas and spaces are used to separate MIME
types, so the robustness principle suggests accepting both as
separators, even if it means that the semicolon is subordinate to the
comma in MIME type lists, which is not the case in ordinary English.

> You now reuse the MIME parameter syntax to say something about the form
> behavior, but not really about the data that the form deals with.  That seems strange.

Strange would be very much better than more delay.

> Any reason in particular for not simply using a parameter called, e.g., "capture",
> which would leave it to the user agent to determine the specific capture device?

The mere presence of an "accept" parameter was supposed to signal that
since HTML 3.2.  Prior to that, <INPUT type="audio" ...> was part of
the 1993 HTML spec.  If we can get this in under the two decade mark,
I'd be happy to support that, too. :)

Received on Wednesday, 16 June 2010 17:21:19 UTC