Re: Promises

> On Sep 28, 2015, at 12:21 , Mike O'Neill <michael.oneill@baycloud.com> wrote:
> 
> It is the responsibility of the site, but it could also be that a UA wants
> to  double-check. The TPS says it, I would strongly resist that being
> portrayed as a bug.
> 
> Irrespective, my point is that asynchronism is intrinsic to the UA
> environment, and the Promise concept responds to that. I agree we should not
> poke into the existing text unless we have to, but the Permission API gives
> us a parallel path. If we don't follow it others may anyway.

OK, but Mike — we had a formal last-call comment from Anne suggesting we use promises, and our consensus reply was that the call was immediate and not asynchronous.  It would be a significant change of direction now.


> 
> I am volunteering to attempt it.
> 
> Mike
> 
> -----Original Message-----
> From: singer@apple.com [mailto:singer@apple.com] 
> Sent: 28 September 2015 18:40
> 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 9:38 , Mike O'Neill <michael.oneill@baycloud.com>
> wrote:
>> 
>> You only know that you have requested it, not that it has been granted.
> 
> It’s been granted.  This was a long conversation we had; since it’s the task
> of the SITE to get the user’s permission, there is nothing in real-time for
> the user-agent to do.
> 
>> 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.
> 
> Then the site should not be calling store…
> 
>> 
>> 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;
> 
> that line may be a bug
> 
>> 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.
> 
> all the rest are right; the user can later revoke
> 
>> 
>> 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.
>> 
>> 
>> 
> 
> David Singer
> Manager, Software Standards, Apple Inc.
> 
> 
> 

David Singer
Manager, Software Standards, Apple Inc.

Received on Monday, 28 September 2015 22:19:20 UTC