RE: Promises

You only know that you have requested it, not that it has been granted.
The use could also have set the UA never to grant an exception, so even if
there is no prompt you still have to check.

>From the TPS:

The user agent MAY provide interfaces to the user:

To indicate that a call to store an exception has just been made;
To allow the user to confirm a user-granted exception prior to storage;
To indicate that one or more exceptions exist for the current top-level
origin;
To indicate that one or more exceptions exist for sites incorporated into
the current page;
To allow the user to see and possibly revoke stored exceptions;
Other aspects of the exception mechanism, as desired.
There is no required user interface for the user agent; a user agent
MAYchoose to provide no user interface regarding user-granted exceptions.

Mik4


-----Original Message-----
From: singer@apple.com [mailto:singer@apple.com] 
Sent: 28 September 2015 17:02
To: Mike O'Neill <michael.oneill@baycloud.com>
Cc: public-tracking@w3.org; Adrian Bateman <adrianba@microsoft.com>; Mounir
Lamouri <mounir@lamouri.fr>; Mike West <mkwst@google.com>
Subject: Re: Promises


> On Sep 28, 2015, at 3:01 , Mike O'Neill <michael.oneill@baycloud.com>
wrote:
> 
> In the last call I reported on some experience of implementing the API,
all of which I will write up soon, but for now I want to expand a point I
made.
>  
> The usual pattern will probably be for script on a first party page ,
after storing an exception,  to check the  tracking status
(confirmSiteSpecificTrackingException or confirmWebWideTrackingException, or
look at the doNotTrack property).
>  
> Even if the UA does not prompt the user but stores the exception
immediately, the status returned from the synchronous property or function
will not have been updated (unless the UA implementation includes an
implicit “yield”). Some construction like:
>  
> storeSiteSpecificTrackingException(propertyBag);
> setTimeout(function(){
>                var result  =
confirmSiteSpecificTrackingException(propertyBag);
>                // take action on result
> }, arbitraryDelay);
>  
> is necessary. 

No, it’s not.  You *know* you have the exception, so you just go ahead.
There is no need to call the confirm API at all, at the time you call Store.

We talked about this, and we decided that we didn’t need any kind of async.

> If a UA implementation of the API only registers the grant after
confirming it with the user, then this code would have to be executed
continuously. The arbitraryDelay adds annoying latency when in many cases it
is unnecessary. Returning a Promise is a much better way to handle this but
that is not how the spec is currently. 
>  
> I have been looking at the draft Permissions API
http://www.w3.org/TR/permissions/ and I wonder if we could leverage this to
create an additional alternate for the synchronous confirm call we have now.
>  
> The Permissions interface has a function, query, that returns a Promise.
At the moment the only PermissionNames defined are “geolocation”,
“notifications”, “push-notifications” and “midi-sysex”.
>  
> We could define a new Permission, with PermissionName “tracking”, with the
appropriate TPS propertyBag properties e.g. arrayOfDomainStrings defined in
the new Permission’s dictionary. We would then have an alternative way for
script to get the status using a method more in keeping with the
asynchronous style. We do not need to change the TPS, just create an
alternative path via a supplement to the Permissions API.
>  
> Can we talk about this next call?
>  
> Mike
>  
>  
> Mike O'Neill
> Technical Director
> Baycloud Systems
> Oxford Centre for Innovation 
> New Road
> Oxford
> OX1 1BY
> Tel. 01865 735619
> Fax: 01865 261401
> <image003.png>
> Email: michael.oneill@baycloud.com
> <image004.png>Professional Profile
> See who we know in common
> Want a signature like this?

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 28 September 2015 16:38:34 UTC