Re: Proposal for a Permissions API

On Wed, Sep 3, 2014 at 3:29 AM, Mounir Lamouri <mounir@lamouri.fr> wrote:
> On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
>> I'm generally supportive of this direction.
>>
>> I'm not sure that that the PermissionStatus thing is needed. For
>> example in order to support bluetooth is might be better to make the
>> call look like:
>>
>> permissions.has("bluetooth", "fitbit").then(...);
>
> That's more Permission than PermissionStatus, right?
>
> What you proposed here would probably be something like that in WebIDL:
> Promise<> has(PermissionName name, any options);
>
> But really, we could make that option bag be a dictionary because it
> gives good context about what you are passing like what does "fitbit"
> means here? Is that a black listed device or a white listed one? The one
> you want to target?
>
> I agree that it might be unusual to have a required "name" than might
> often be used alone but it makes the API way more javascript-y and self
> explanatory. IMO, this call is nicer to read than the one you wrote
> above:
>   permissions.has({ name: 'bluetooth', devices: 'fitbit' });
> because I understand what the call is trying to do. In addition, as you
> pointed, it gives a lot of flexibility.

Belatedly, I'd like to suggest a slightly different model. Instead of
trying to stuff arbitrary queries into the permissions.has() call,
maybe expose the current permissions as data, and let the application
inspect them using custom code. This is likely to work better for
Bluetooth, since we're planning to have pages request devices by the
Services they expose, not their deviceIds, and a page may want to
check for either an available device exposing some services, or that a
device they've already opened hasn't been revoked.

Getting permission revocation to update a UI correctly is also an
interesting problem. You could expose an event on permission change,
but given that templating frameworks are moving toward
Object.observe() to update themselves in response to model object
changes, that would require developers to write extra code to
propagate the permission changes into their models.

So what if navigator.permissions just _was_ a suitable model object?
Make it, say, a Map from permission-name to an object defined by the
permission's standard, and extend Map to expose enough synthetic
change records that Object.observe(a_map) is useful.

Jeffrey

Received on Wednesday, 1 October 2014 17:35:18 UTC