Browsers mostly are based on multiple processes and threads of execution. Many things happen in parallel i.e. asynchronously such as the different browser tabs, separate "browsing contexts" in embedded iframes, loading of resources etc. This is especially important for APIs that deal with cross-domain activities as DNT has to. The code to calculate what the DNT header should be for a particular request needs to operate asynchronously and usually is executed in an entirely different process than a particular browsing context.
JavaScript is designed to be single-threaded, there is no yield, pre-emption or need for a spin lock.
The only way to model parallel activities is to use callbacks. If a piece of code needs to run later or at intervals then there is the built-in function setInterval and setTimeout which take a call back function as an argument. When the timeout/interval elapses the callback function is queued to be called after all the code sequences in the current document has completed, there is no pre-emption.
Similarly any API that deals with delayed execution, which is necessary for example if data needs to assembled across different origins such as the web-wide or site specific "DNT exceptions" needs to be support a callback function. For example if some code registers DNT:0 for a subresource then initiates an XHR to send a request , the DNT value will probably be wrong (i.e. still set) if there is no intervening delay. This means that at the moment any call to the JavaScrpt API must be followed by a call to setTimeout to allow the exception time to be executed.
The modern way to use callbacks is Promises, many APIs now support them and the intrinsics are built in to the latest version of JavaScript.
Here is a brief description: https://spring.io/understanding/javascript-promises
As we have discussed in the past we should amend the API so all functions return a Promise to guarantee asynchronous completion at the time the Promise is resolved.
The Promise has a fulfilment value, i.e. a JavaScript object, named TrackingStatusObject .
A TrackingStatusObject (TSO) contains a DOMString Status indicating the success or failure of the call. Although all calls with valid parameters can be assumed to succeed, there needs to be a way to indicate if the parameters were wrong. We could also return other properties here but that will be the subject of another Issue, as will other additions to the API.
partial interface Navigator {
Promise<TrackingStatusObject>
storeSiteSpecificTrackingException (TrackingPermission properties);
Promise<TrackingStatusObject>
confirmTrackingException(TrackingPermission properties);
};
dictionary TrackingStatusObject {
DomString Status; // string value indicating "OK" for success or any other value for failure
DOMString Version; // a string indicating what version of the API is supported by this implementation.
// this is encoded as {major-version-number}.{minor-version-number}
// e.g. "1.0" can signify the current version.
};
dictionary StoreExceptionPropertyBag {
DOMString? domain;
DOMString? siteName;
DOMString? explanationString;
DOMString? detailURI;
DOMString? expires;
long? maxAge;
};
dictionary TrackingPermission : StoreExceptionPropertyBag {
};
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3