W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: Allow ... centralized dialog up front

From: Keean Schupke <keean@fry-it.com>
Date: Sat, 2 Feb 2013 10:59:13 +0000
Message-ID: <CAFpgLgK-i7j1QnxTiwPuARL10-aE6_grpGA1H-rkaBasQVFZhQ@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: Arthur Barstow <art.barstow@nokia.com>, Charles McCathie Nevile <chaals@yandex-team.ru>, Adrienne Porter Felt <adriennefelt@gmail.com>, WebApps WG <public-webapps@w3.org>
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.
>>>
>>
>
Received on Saturday, 2 February 2013 10:59:40 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:57 GMT