W3C home > Mailing lists > Public > public-device-apis@w3.org > December 2009

RE: Core Device APIs

From: Suresh Chitturi <schitturi@rim.com>
Date: Wed, 2 Dec 2009 13:33:52 -0500
Message-ID: <B35D8F122C08BC43BBA1D02713D2BB5D082B0313@XCH69YKF.rim.net>
To: "Doug Turner" <w3c@dougt.org>, "Robin Berjon" <robin@robineko.com>
Cc: <public-device-apis@w3.org>
Why don't we instead use the dom style methods such as
addEventlistener() and removeEventlistener for async operations compared
to pendingOp style? I say this because developers are used to then well.

Functionally, are they any different?

Regards,
Suresh

-----Original Message-----
From: public-device-apis-request@w3.org
[mailto:public-device-apis-request@w3.org] On Behalf Of Doug Turner
Sent: Wednesday, December 02, 2009 11:27 AM
To: Robin Berjon
Cc: public-device-apis@w3.org
Subject: Re: Core Device APIs

Hi Robin,

fwiw, geolocation wouldn't use device.cancel().  in some of our early
discussed we had a notion of cancelAll() that would cancel all pending
geolocation requests.  To make the API simpler, we dropped this form.
Instead, every call to cancel needs to pass a request id:


var watchID = navigator.geolocation.watchPosition(successCallback,
failureCallback, null);
....
navigator.geolocation.clearWatch(watchID);


Other APIs that we have discussed in the Geo WG have been accelleration
and orientation.  In both cases, we have been considering using dom
style events (addEventListener) and the right way to cancel in this
model is to just call removeEventListener.

Regards,

Doug Turner


On Dec 2, 2009, at 5:34 AM, Robin Berjon wrote:

> Hi,
> 
> I've updated http://dev.w3.org/2009/dap/device/ to hold PendingOp as
well. I'd welcome review of this (short) specification, and reuse of it.
If people agree, this is a contender for swift publication.
> 
> --
> Robin Berjon
>  robineko - hired gun, higher standards
>  http://robineko.com/
> 
> 
> 
> 
> 




---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Wednesday, 2 December 2009 18:34:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:14:02 GMT