- From: Rich Tibbett <rich.tibbett@gmail.com>
- Date: Tue, 21 Sep 2010 13:03:09 +0200
- To: Robin Berjon <robin@robineko.com>
- Cc: public-device-apis@w3.org
- Message-ID: <AANLkTinB9JJ-ddJ2tzPpXzRQZ2PK_9C+4OTaiuANimLH@mail.gmail.com>
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. Rich
Received on Tuesday, 21 September 2010 11:04:04 UTC