W3C home > Mailing lists > Public > public-geolocation@w3.org > November 2011

Re: revoking permission after granting permission

From: Simon Pieters <simonp@opera.com>
Date: Thu, 10 Nov 2011 12:34:28 +0100
To: "Steve Block" <steveblock@google.com>
Cc: public-geolocation@w3.org
Message-ID: <op.v4qafqp8idj3kv@simon-pieterss-macbook.local>
On Thu, 10 Nov 2011 11:46:54 +0100, Steve Block <steveblock@google.com>  
wrote:

> Hi Simon,
>
> Thanks for the comment. I think you might be misinterpreting the spec.
>
>> I think getCurrentPosition should only invoke at most one callback,  
>> either
>> success or error.
> That is already the case.

Not if the user first allows and then changes his mind and denies. The  
text in the spec clearly says that if the user denies, the error callback  
must be invoked. If you intend it to not be invoked in this case, the spec  
needs to say so.

> The text you quote means that if the user
> denies permission, the error callback must be called with code
> PERMISSION_DENIED, as opposed to with any other error code, even if
> other errors were encountered during the algorithm above. In all
> cases, the error callback is invoked at most once. The text is
> 'overriding' the algorithm, because we don't include the permission
> acquisition process in the algorithm itself.
>
> For both getCurrentPosition() and watchPosition(), the spec considers
> the acquisition of permission to be a one-time, single event, per
> method call. Any caching of user permissions is left up to the UA.
>
> You're right that the spec does not say anything about what to do if a
> permission is cached by the UA but then changed by the user while a
> call to getcurrentPosition() or watchPosition() is in progress. Your
> suggestion of stopping a watch seems reasonable, but I don't think
> it's necessary to include this in the spec.

I think it would be helpful for implementors if it was in the spec.

> Thanks,
> Steve


-- 
Simon Pieters
Opera Software
Received on Thursday, 10 November 2011 11:33:03 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 22 March 2012 18:13:56 GMT