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

Re: Capture API question

From: Robin Berjon <robin@robineko.com>
Date: Fri, 11 Jun 2010 16:51:31 +0200
Cc: Dominique Hazael-Massieux <dom@w3.org>, public-device-apis@w3.org
Message-Id: <729DC260-CD32-4268-8CE8-1CAD371B2CDB@robineko.com>
To: Andrei Popescu <andreip@google.com>
Hi Andrei,

On Jun 11, 2010, at 12:21 , Andrei Popescu wrote:
> No, we're not implementing the ViewFinder interface. We're just
> hooking the camera to the file picker. The only extension we're
> considering is to allow the author to invoke the camera directly using
> <input type="file" accept="image/*;source=camera">
> UAs that don't know what "source=camera" is will just pop up a regular
> file picker.

That does indeed provide for a nice fallback strategy. It would seem to me that no matter how simple, the source parameter could use being put in a spec. I'm guessing you have something like the following?

  - image/*;source=camera
  - video/*;source=camera
  - audio/*;source=microphone

Would it make sense to make it source=device for all three?

Question: are you looking just at stills now or also AV content (seems to me like both)? I ask because with AV there could be value in letting the user select one compound input device (e.g. "My WebCam") but have separate access to the audio and video afterwards. But that might be a future refinement.

Also: browsers tend to like exposing a native UI for file pickers as that's a whole lot more natural for users, but on many platforms they don't have an option to pick from an input source. I can see how you could address that on Android, but I'm curious as to how you plan to handle it with other platforms.

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.

>> *are you implementing an additional set of methods on top of the File
>> API for media objects?
> Not for now but we are considering exposing the properties of the
> captured media (e.g. dimensions, duration, encoding, etc) using a
> subtype of File, like MediaFile in your spec.

If you're going to use something "like MediaFile", how about we chat about what you'd like to put there and see if we can't just align?

Robin Berjon
  robineko  hired gun, higher standards
Received on Friday, 11 June 2010 14:52:04 UTC

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