Re: The Media Capture API FPWD

On 21-Sep-10 10:27, Ilkka Oksanen wrote:
> 21/09/2010 16:00, ext Dominique Hazael-Massieux kirjoitti:
>> That doesn't seem like a proper outcome — dismissing user’s data 
>> shouldn’t be something we encourage in general. Imagine that the
>> user has been spending a lot of time to get the perfect picture, only
>> to get it randomly trashed by the original invokator.
>>
>> I think once the external app is up and running, canceling a pending 
>> operation should have no direct effect on the external app. It might
>> be OK to cancel the invokation of the callbacks.
>>
> Right. That was the most straightforward approach I could think of. I
> don't see cancel() very useful if it doesn't have any effect on external
> app or callbacks. In such case PendingOp could even be removed from the
> Capture API.
>
> Deleting the files is probably overkill but I still think that
> cancel() should give the control back to the script. If cancel() is
> included it should in minimum save the possible unfinished recordings,
> close the camera app, and call success callback if there are any files.
>
> The user is recording content for the app and if the app decides that it
> wants to stop the operation using cancel() and potentially will not
> process the result at all then there is not much point for allowing the
> user to continue?

I think that the files have to be deleted as there is no way for the
webapp to find them in the absence of a success callback (which is the
step that provides the URI). You might argue that there should be a
success callback after each image (or video clip) is recorded, and I
would certainly support that model.

You might ask what the difference between capturing 30 images and
generating 30 success callbacks as one operation, or doing 30 operations
of capture 1 image with 1 success callback each. I think that many of
these camera capture apps will have some sort of startup overhead
(including possibly resetting any preferences, possibly getting user
consent, choosing the camera to use [front or back]) that will make the
second approach less than desirable.

Philip

-- 
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 Tuesday, 21 September 2010 17:16:20 UTC