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

Re: ISSUE-44 (apiHanging): What do APIs hang off of? [APIs â General]

From: イアンフェッティ <ifette@google.com>
Date: Thu, 12 Nov 2009 01:51:09 -0800
Message-ID: <bbeaa26f0911120151g3a708c35x20635639120e2d8a@mail.gmail.com>
To: Device APIs and Policy Working Group WG <public-device-apis@w3.org>
2009/11/12 Device APIs and Policy Working Group Issue Tracker <
sysbot+tracker@w3.org <sysbot%2Btracker@w3.org>>

> ISSUE-44 (apiHanging): What do APIs hang off of? [APIs — General]
> http://www.w3.org/2009/dap/track/issues/44
> Raised by: Robin Berjon
> On product: APIs — General
> one issue we have with APIs is also how they are exposed. Say for
> instance that the Contacts API has a basic interface providing access
> to the rest of the functionality called "Contacts". We could:
> 1) Make it available as a constructor:
> 2) Make it available as an object already instantiated in the global
> scope
> 3) Make a way of requesting that an API be "loaded"
> 4) Use an object to provide access to all the device APIs
> 5) Hang it off from a markup element
> 6) Hang it off from an event object
I suspect 5 or 6 may be easiest from a security perspective, but as noted
below i think this will surface in discussions on an api-by-api  basis.

> Discussion thread starting at:
> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0008.html
> which lead to the following observations:
> • window.navigator has been used many times for this type of APIs
> • a possible window.navigator.device host for the DAP APIs, with the start
> of a spec at http://dev.w3.org/2009/dap/device/Overview.html
> • the need to look at on an API-per-API basis, taking into account the
> security model, the activation model (e.g. from an event, a markup element),
> the locking model wrt Web workers
> • the need to watch for clashes in existing Web content
> (the latter two points having been raised by Hixie
> http://lists.w3.org/Archives/Public/public-device-apis/2009Oct/0122.html)
Received on Thursday, 12 November 2009 09:51:49 UTC

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