Re: Allow ... centralized dialog up front

I didn't think of that. The app would have to maintain its own set of
permission flags updated by the callback. I am not sure that's easier than
just chaining an anonymous function... But I guess that's a programming
style issue.

Cheers,
Keean.
 On 2 Feb 2013 10:47, "Florian Bösch" <pyalot@gmail.com> wrote:

> 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.
>>>
>>
>