Re: PendingOperation (was Re: CfC: The Media Capture API FPWD)

On Tue, Sep 21, 2010 at 1:03 PM, Rich Tibbett <rich.tibbett@gmail.com>wrote:

> On Tue, Sep 7, 2010 at 4:05 PM, Robin Berjon <robin@robineko.com> wrote:
>
>> On Sep 3, 2010, at 15:45 , Philip Gladstone wrote:
>> > * 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?
>>
>> We need to better define PendingOperation across all our specs that use
>> it. The first thing to note is that actually cancelling the device operation
>> can only be a SHOULD — in some cases it can't be done without the UA being
>> able to do much about it. What's important is that we make sure that the
>> code behaviour is consistent and works for authors.
>>
>> The second part is that we should define callback operations in terms of
>> event loops, tasks, and task queues so as to ensure their interoperability
>> (and integration). For more detail, see:
>>
>>  http://dev.w3.org/html5/spec/webappapis.html#event-loops
>>
>>
> I took a stab at adding this second part in to the latest Contacts API ED.
> The CVS diff log is here:
> http://dev.w3.org/cvsweb/2009/dap/contacts/Overview.html.diff?r1=1.87&r2=1.88&f=h
>
> I'm unclear whether we can (or you intended to) make PendingOperation the
> single event source for both success and error callbacks or whether we need
> separate event sources for each (the callback interfaces themselves). I
> opted for the former which will require changes to the Core Device
> Specification to reflect PendingOperations status as an event source.
>
> Anyway, it's just a stab and if I got this right the first time around I'd
> be quite surprised.
>

s/event source/task source