RE: First stab at the Capture API (aka Camera API)

Philip,
You are right about that the API does not address the use cases in the current spec. Also, your suggestion below as “The one thing that would improve the situation will be to able able to get the actual data (preferably in real time) from the capture process. Specifying that the URI provided in the captureCB was a websockets capable URI would solve the problem. Alternately, making sure that XHR can get the data (there are probably some same origin issues here) would solve most of the use cases” could apply here.

I will let others comment on what would be a good model?

I think Robin’s opinion is to keep it as Capture only for v1.0.

Thanks
Dzung Tran.

From: Philip Gladstone [mailto:pgladstone@cisco.com]
Sent: Wednesday, December 02, 2009 08:16 AM
To: Dominique Hazael-Massieux
Cc: Tran, Dzung D; public-device-apis
Subject: Re: First stab at the Capture API (aka Camera API)

Dominique Hazael-Massieux wrote:

Le mardi 01 décembre 2009 à 19:50 -0800, Tran, Dzung D a écrit :



It is checked in to CVS as stated below. There is some formatting

problems, which I am strap for time to figure out right now.

http://dev.w3.org/2009/dap/camera/Overview.html






I have fixed the formatting problems, and am fixing bugs and adding

clarifications as I find them.



Thanks for a great start!



I think the document is quite close to a FPWD, as Robin mentioned; to

facilitate the discussion on that point (i.e. to evaluate if we cover as

much as the final scope as we want), here is a list of the requirements

*it does NOT fullfill* to do at this point:

      * must enable listing the available cameras

      * must enable listing the available audio input devices

      * must enable listing the available formats and codecs, *per

        capture device*

      * must enable choosing preferred aspects of the captured content

        (e.g. width, height, format, frame rate)

      * should enable control of the camera's capabilities (e.g. zoom,

        luminosity, night mode, focus mode)

      * should enable setting of brightness, contrast, gain

      * should enable displaying a viewfinder as part of the document

        (e.g. as a video element [HTML5])

      * should enable setting microphone audio level



Dom




I think it would also be useful to note which of the five use cases in section B are currently supported by the proposed API.

[I'm assuming that the permissible uses of the media URIs return by captureCB will be defined. For example, can you XHR against them to get the data?]

Picture Capture and Picture upload: If the issues are resolved, then I think that this use case is met.

Panorama Image Capture: Doesn't seem likely unless there is a way to get the data from the media URL.

Video chat: Not possible as there is no way to capture a video stream and transmit it in real time (audio similarly)

Web cam: Motion of the camera could be via some other API. Motion detection requires that the image data be available to the app -- so currently not possible.

Voice memo: There is the same set of issues as for the picture capture use case.

Thus it appears that we are 0 for 5. The one thing that would improve the situation will be to able able to get the actual data (preferably in real time) from the capture process. Specifying that the URI provided in the captureCB was a websockets capable URI would solve the problem. Alternately, making sure that XHR can get the data (there are probably some same origin issues here) would solve most of the use cases.

Philip





--

Philip Gladstone                    978-ZEN-TOAD (978-936-8623)

Cisco Systems, Inc                                  Boxboro, MA