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

Re: The Media Capture API FPWD

From: Ilkka Oksanen <Ilkka.Oksanen@nokia.com>
Date: Tue, 21 Sep 2010 17:27:59 +0300
Message-ID: <4C98C0EF.9030500@nokia.com>
To: ext Dominique Hazael-Massieux <dom@w3.org>
CC: ext Bryan Sullivan <blsaws@gmail.com>, W3C DAP <public-device-apis@w3.org>
21/09/2010 16:00, ext Dominique Hazael-Massieux kirjoitti:
>> There is indeed need for clarification. It's now explicitly said 
>> that the native application is automatically closed, the incomplete
>> set of files that the user might have captured is destroyed and no
>> callbacks are invoked.
> 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?

Received on Tuesday, 21 September 2010 14:28:42 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:53:46 UTC