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

ACTION-74: Propose options to move forward with Capture

From: Robin Berjon <robin@robineko.com>
Date: Wed, 13 Jan 2010 14:52:02 +0100
Message-Id: <6B36E0FB-64A7-4E81-8639-67DB7FCDD7E3@robineko.com>
To: public-device-apis@w3.org
Hi all,

here is a three-level suggestion to move forward with the Capture API. It is an attempt to find a path towards consensus on what to write and what to publish.

The three levels that I have in mind are:

 Snapshot capture, external view/sound finder
  This is essentially what could already be done today (has been done in at least Opera Mini): you click a file input button and instead of just a file picker you can also take a picture, or record AV content.
  In trusted runtimes, you can synthesise the click even to get the same result (using jQuery, $("<input type=file accept=image/*").bind("change", sucCB).click() is all you ought to need).
  It may be useful to capture this in a (probably non-normative, except perhaps for what to do in trusted cases) document, to clarify the topic and possibly plug some holes.

 Snapshot capture, embeddable view/sound finder
  As has been discussed earlier, this requires a simple API addition to the existing <input> apparatus. A possible proposal for this has been described at http://www.w3.org/mid/165A9ED1-009D-4EDB-AA7D-689B2326DB92@robineko.com. This proposal can be refined to include some desirable aspects that have been requested (such as controlling the likes of zoom, aperture, etc.).
  This would require a normative specification, but it shouldn't need to be very complicated.

 Streaming capture
  The basic use case for this is videoconferencing, which has more advanced requirements. It corresponds to the <device> discussion.


WDYT?

--
Robin Berjon
  robineko  hired gun, higher standards
  http://robineko.com/
Received on Wednesday, 13 January 2010 13:52:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:45:57 UTC