- From: Mike O'Neill <michael.oneill@baycloud.com>
- Date: Mon, 26 Sep 2016 10:41:11 +0100
- To: "'Nick Doty'" <npdoty@ischool.berkeley.edu>, "'Matthias Schunter \(Intel Corporation\)'" <mts-std@schunter.org>
- Cc: <public-tracking@w3.org>
Hi Nick, Returning a Promise is not about waiting for the user to confirm, but about basic software architecture. If the TrackingException functions are synchronous any script that uses them has to poll (using setInterval ) before it can be sure the browser has actioned it. For example, if you intend to trigger an XHR and you need DNT:0 to go with that it will fail every time unless you have executed a setInterval beforehand. If you look at the code for my test page https://baycloud.com/dntapi at https://baycloud.com/Modules/Baycloud.API/Scripts/apitest.js and you can see the convolutions needed to get round the synchronous call. Note it is not only the store calls but also confirm and revoke. It also applies to the navigator.doNotTrack property which has to be a disguised function anyway. I mentioned this last year after experience on sites using Bouncer. I originally (back in 2013) used the MS implementation where you had to wait for a page reload before it was actioned, so the need for setInterval was not obvious then. With bouncer the action is immediate but can only be communicated after the completion of the current thread, so needs an asynchronous callback. All this arises from the single threaded reality of javascript, and this is why all API functions that involve a delayed effect are now recommended to use Promises. Without it you almost always have to add setInterval calls with an async callback (anyway), which is annoying for developers. Mike
Received on Monday, 26 September 2016 09:42:22 UTC