RE: ACTION-74: Propose options to move forward with Capture

Level 1: can definitely documented as non-normative section in the Capture specification.

Level 2: like stated below would require additional API such as viewfinder support and camera control

Level 3: I think would need a new set of APIs which overlap with some of the APIs in Level 2. 

So here is my thought, since there will be some overlap of Level 2 and Level 3, why don't we just go all the way with Level 3 and document Level 1 in a non-normative section.

Thanks
Dzung Tran

-----Original Message-----
From: public-device-apis-request@w3.org [mailto:public-device-apis-request@w3.org] On Behalf Of Robin Berjon
Sent: Wednesday, January 13, 2010 05:52 AM
To: public-device-apis@w3.org
Subject: ACTION-74: Propose options to move forward with Capture

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, 20 January 2010 14:54:21 UTC