Re: CfC: The Media Capture API FPWD

 * The current draft does not appear to permit the web app to choose
which camera to use -- presumably this will be a choice presented to the
user when the camera app is started. Is this intentional? For example, I
have a four port video capture device. I would like to be able to say
'capture picture on each device in turn, and send the results to my
server, forever'. Once I have provided the permission to do that, it
ought to do that. However, I can't choose the input port, and I can't
say 'automatically take picture' (unless this is an option of the camera
app).

* It is unclear (to me) whether the MediaFile that is returned when a
capture completes is persistent or not. Also, the handling of it will be
rather different if it is a data: url. The issue here is what happens if
the web app loses the MediaFile. Does the underlying image continue to
exist (potentially consuming space on a memory card)? Can these
MediaFile references be recovered in a later session?

* Is the cancel on the PendingOperation synchronous? I.e. once that
method returns, has the PendingOperation been cancelled, or is it only
canceled when (for example) the errorCB is called with a 'CANCELED'
error status. If an image capture is cancelled once the user has
captured one image, is that image lost, or does it get returned on a
successCB? If it is lost, does it remain in persistent storage?

Apologies if these questions are too detail oriented...

Thanks

Philip

On 01-Sep-10 15:37, Frederick.Hirsch@nokia.com wrote:
> Hi all,
>
> Robin is away, but we agreed  at the teleconference today to start a call for consensus on the Media Capture API, ending next week ( publication will include the change from ACTION-267 to add the note regarding ISSUE-101 to the text, this has not been done yet.) [1]
>
> This is a call for consensus to see if there are any objections to publishing the Media Capture API as a FPWD.
>
> The draft can be read at:
>
> http://dev.w3.org/2009/dap/camera/Overview-API.html
>
> Note that there is no requirement on API FPWDs to be perfect — if they were perfect we'd go straight to LC. They need to be good for broader review, and reasonably feature-complete.
>
> Where CfCs are concerned, silence is considered to be assent, but positive support is preferred (even if simply with a +1). Please send feedback before next Tuesday (Sept 6) as much as possible.
>
> Thanks!
>
> regards, Frederick
>
> Frederick Hirsch, Nokia
> Co-Chair, W3C DAP Working Group
>
>
> [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Sep/att-0007/minutes-2010-09-01.html#item08
>
>
>
>

-- 
Philip Gladstone
Distinguished Engineer
Product Development
pgladstone@cisco.com
Phone: +1 978-ZEN-TOAD (+1 978 936 8623)
Google: +1 978 800 1010
Ham radio: N1DQ
Blog: http://wwwin-blogs.cisco.com/pgladsto/

Cisco.com - http://www.cisco.com

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

Received on Friday, 3 September 2010 14:46:34 UTC