Re: [whatwg] Proposal: navigator.cores

On Wed, Jul 2, 2014 at 9:04 PM, Joshua Cranmer <Pidgeot18@verizon.net>
wrote:

> 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.


I don't think this is different from any other feature. It was discussed,
some people objected, others liked it and now there are 2 implementations.
Just because it's in a spec doesn't mean that people won't object any more.
It will likely be just the opposite! (See your reaction)


> 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.
>

facts = 2 implementations. I certainly didn't say anything else.
Please also note that this thread has over 70 messages so it's not as if I
initiated it.


> 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.


Not sure if I feel like re-debating these points. (we can if you want to)
I do feel strongly that a low level API is more desirable than the proposed
high level solutions.

Received on Wednesday, 2 July 2014 19:22:06 UTC