- From: Suresh Chitturi <schitturi@rim.com>
- Date: Wed, 29 Sep 2010 09:09:24 -0500
- To: "Dominique Hazael-Massieux" <dom@w3.org>
- Cc: "public-device-apis" <public-device-apis@w3.org>
-----Original Message----- From: Dominique Hazael-Massieux [mailto:dom@w3.org] Sent: Wednesday, September 29, 2010 4:23 AM To: Suresh Chitturi Cc: public-device-apis Subject: RE: updated draft of Permissions for Device API access (was "Device API Features and Capabilities") Le mardi 28 septembre 2010 à 13:07 -0500, Suresh Chitturi a écrit : > Suresh>> The use case is I would only grant permission for one time > which translates to getCurrentPosition() and in some cases I would be > fine to grant permission for continuous monitoring and that is > watchPosition() and yet in another case I don’t care about the details > and grant for both getCurrentPosition() and watchPosition(). But who is "I" in this context? The user? thhe policy framework? Suresh>> All of the above? getCurrentPosition() is only distinguishable from watchPosition() when it is limited in number, and wathcPosition() can be made equivalent to a getCurrentPosition() by limiting it in duration. The number/duration limitation parameter seems important, but I think it's orthogonal to the actual permission that is granted, and probably ought to be specified separately (e.g. through a <param> element in the <feature> element of widgets P&C). Maybe we should start collecting these parameters as part of the document? > Suresh>> My understanding is that these identifiers can be used in > with the <feature> element prefixed with a URI as described in the 1. > Introduction. And what I was merely suggesting is that a complementary > statement be added that these identifiers can also be used in > conjunction with the <access> element. But that doesn't seem to match what WARP currently allows; I don't know how you would specify that only example.com can make use of geolocation within the current form of WARP: http://www.w3.org/TR/widgets-access/ That might be a worthwhile complement to WARP (in which case it should be written up as a concrete specification), but I don't think it makes to refer to it if it isn't specified yet. Suresh>> This was my understanding that WARP allows you to control which domains can access the APIs listed under <feature> elements. Robin is an expert on this and we should seek his input. Dom --------------------------------------------------------------------- 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, 29 September 2010 14:10:16 UTC