Re: [sensors] Use simple event dispatch mechanism instead of task source (queued)

> I meant that changing it in the middle of an event turn could be observable in JS. Sorry for the confusion.

No problems, sorry, maybe I was also unclear. Shared buffer is internal implementation detail and internal slot, good implementation would treat it this way. External behavior must be same regardless of implementation details. Thus, in chromium, if shared buffer is updated in the middle of the script, it will not be observable on JS side, e.g., `sensor.reading === sensor.reading` should be respected. That's why @pozdnyakov is fixing it in #210, to sync spec with agreement we made.

> Yeah, that's not the same issue at all. This was about the reading object being immutable.

Was there a time when we had issue just about one thing 😃  ?

Rick [proposed](https://github.com/w3c/ambient-light/issues/15#issuecomment-257926023) quite nice set of tests and everyone agreed, issue closed and implemented in chrome according to agreement.

```
// In this turn, sensor.reading attribute's value will always be the same SensorReading object
console.log(sensor.reading === sensor.reading);
```
> For reference, here's the log of our conversation on #whatwg: http://logs.glob.uno/?c=freenode%23whatwg#c1029330

Thanks, you asked on irc about other specs, you might want to check IDB, WebSockets and if I remember correctly MediaStream interface.

>>Do you want to keep task source event processing model?

>We don't have that now. So I'm not sure what you mean.

We have mixed model :D Sensor is a task source that should add events to the queue, and it should stop (start) queue processing when visibility changes.

-- 
GitHub Notification of comment by alexshalamov
Please view or discuss this issue at https://github.com/w3c/sensors/issues/215#issuecomment-304331219 using your GitHub account

Received on Friday, 26 May 2017 16:44:20 UTC