W3C home > Mailing lists > Public > public-device-apis@w3.org > June 2011

Re: Device API suggestion

From: Robin Berjon <robin@berjon.com>
Date: Tue, 14 Jun 2011 12:58:10 +0200
Cc: public-device-apis@w3.org
Message-Id: <C70E1388-23B1-43CD-BE64-13441B49983E@berjon.com>
To: Tyler Potter <typotter@google.com>
Hi Tyler,

On Jun 10, 2011, at 01:23 , Tyler Potter wrote:
> I am a software engineer working at Google in the mobile search ad space, and we're always looking for ways to improve our users' experience. The opportunities for us to do so are much greater in the mobile space, due to the increased amount of information available, such as geo location, compass and accelerometer sensor information.

This is indeed an area with great potential, and you might be interested to know that Apple have implemented parts of older versions of our Calendar (http://dev.w3.org/2009/dap/calendar/) and Messaging (http://dev.w3.org/2009/dap/messaging/) APIs as part of iAds.

> After doing a little research I came upon the "Device APIs Requirements" document (http://www.w3.org/TR/dap-api-reqs/), and was pleasantly surprised by the amount and variety of capabilities the working group has discussed and recommended for inclusion in the API.

Unfortunately that document is well outdated. The idea was to list there pretty much everything that people suggested could be part of our work, with the subsequent goal of whittling it down to what was actually realistic. This latter step has happened as part of the actual specification documents that we have been working on, but hasn't been reflected in the initial draft. We have a standing action to update the requirements as they are misleading  I have half a mind to pull that publication if we don't update it soon enough as it causes some confusion.

> There is one capability I find strange to be missing from the list, and that is the ability to retrieve the phone number of the device (if available). Accessing the phone number obviously carries a privacy concern, however, many of the other bits of system information (especially geo location) are just as, if not more sensitive. I thought this requirement would fit in nicely in the System Information section alongside the other network related bits such as network type and status.

There is a major privacy concern in accessing the user's personal information and we would want to be extremely careful in making that happen. If protected by sufficient security however, I understand the use cases and in fact as a user there are quite a few times when I'd be happy for such functionality to be available.

I don't think that this falls under System Information however (System Information is being split into smaller specs anyway to as not to be one big behemoth of unwieldy data). I would see it as an independent extension to the Contacts API (http://dev.w3.org/2009/dap/contacts/).

IMHO such an API falls under the existing remit of the WG as part of the Contacts API and wouldn't require a change to our charter. I do think however that we'd have to talk with the Identity in the Browser people (http://www.w3.org/2011/identity-ws/) but that shouldn't be a major hurdle.

The greatest barrier to making this happen however (beyond making sure that adequate security can be provided, which I'm pretty sure that we can do if we put our minds to it) is manpower. We have a large remit and too few specification editors to match. So if you could join the group on behalf of Google and help out write such a specification, it would certainly help make it happen!

>  I thought there might be more info in the Network Information API (from http://www.w3.org/2009/dap/), but the link on that page gives a "document not found error" ((http://www.w3.org/2011/WD-netinfo-api-20110607/).

That link is missing a /TR/ before the 2011, which is a bug. Apparently, it's already been fixed. That document won't give you more information about what you're looking for though.

Thanks a lot for your input, it is most helpful!

Robin Berjon - http://berjon.com/ - @robinberjon
Received on Tuesday, 14 June 2011 10:58:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:32:29 UTC