On 7/2/2014 8:31 AM, Rik Cabanier wrote:
That thread concluded with a "let's see how this feature is going to
be used before we commit". Blink and WebKit certainly are in favor.
I went back and looked at the later messages in that thread. Your
argument implies that a plurality of engines implementing this feature
would mollify the detractors, and that is certainly not my reading.
People brought up serious concerns about the utility and wisdom of this
API, and summaries like yours very much feel like an attempt to avoid
addressing those concerns by creating "facts on the ground" instead.
The concerns I recall off the top of my head, to wit:
1. Fingerprinting
2. Use of the API is implicitly assuming that the browser uses only one
thread, which is not a safe assumption.
3. The existence and probable eventual takeover of asynchronous multiple
core architectures.
4. There are better ways to achieve the desired use cases.
I've personally mused that the usual motivation for this feature is
essentially predicated on the notion that there is too much work to be
assigned for a "weak" computer, yet the advocates of this API respond to
comments about the problems involved with high dynamic usage of the
computer with "the scheduler can solve it"--the same scheduler whose
inability to cope with too much work is the basis for the API in the
first place.
--
Beware of bugs in the above code; I have only proved it correct, not tried it.
-- Donald E. Knuth
