Re: Allow ... centralized dialog up front

Usually games (especially 3D applications) would like to get capabilities
that they can use out of the way up front so they don't have to care about
it later on.


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

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