Re: Allow ... centralized dialog up front

And you can have the *the* callback (singular, centralized) as
onAPIPermissionChange just fine.

If you want to improve things for the user and the developer, you can't go
with a solution that doesn't make it any easier for the developer. Your
solution will be ignored, nay ridiculed. If you want developers to play
along, you've got to give them some carrot as well.


On Sat, Feb 2, 2013 at 11:43 AM, Keean Schupke <keean@fry-it.com> wrote:

> There are benefits to the user, in that it allows all permissions to be
> managed from one place.
>
> I am not sure I like the idea of making the popups an application thing. I
> think it should be decided by the browser. In any case you would still need
> the ...Allow callbacks as the user may have gone to the permission
> review/edit page and disabled some permissions since the app started.
>
> Cheers,
> Keean.
>
> Cheers,
> Keean.
>  On 2 Feb 2013 10:27, "Florian Bösch" <pyalot@gmail.com> wrote:
>
>> On Sat, Feb 2, 2013 at 11:16 AM, Keean Schupke <keean@fry-it.com> wrote:
>>
>>> I think a static declaration is better for security, so if a permission
>>> is not there I don't think it should be allowed to request it later. Of
>>> course how this is presented to the user is entirely separate, an the UI
>>> could defer the request until the first time the restricted feature is
>>> used, or allow all permissions that might be needed to be reviewed and
>>> enabled/disabled in one place.
>>>
>> That kills any benefit a developer could derive. The very idea is that
>> you can figure out up front what your user is gonna let you do, and take
>> appropriate steps (not adding parts of the UI, presenting a suitable
>> message that the application won't work etc.) as well as that if a user has
>> agreed up front, that you can rely on that API and don't need to
>> double-check at every step and add a gazillion pointless
>> onFeatureYaddaYaddaAllowCallback handlers.
>>
>