Re: [sensors] Should sensors be singleton?

Okay, so this issue went all over the place.

1. I'm getting more of the Promise vs. factory issue to get at the 
EventSource here, with a slight twist around the possibility to have a
 fallback system tied to subclasses of sensors that _might_ require a 
promise-based solution (as explained by @richtr above). I suggest we 
move that conversation out of here and into the relevant issue (#9).

2. There seems to be agreement and valid use cases for enabling 
multiple instances of the same sensor type to be generated, not only 
for the case where there are multiple sensors of the same type on a 
given device, but also for providing flexibility to the developer(s), 
e.g. to allow different parts of an application to rely on different 
frequency updates of the same sensor. This I'll turn into a 
resolution.

3. There seems to be consensus that whatever the frequency of the 
Sensor instance is, the value property should point to the freshest 
data available, so that two instances of the same Sensor constructor 
would hold the same value during a single event turn. This will be a 
second resolution.

4. Lastly remains open the question of the immutability and === of the
 dictionary-like objects representing values that will end up in the 
data property of the dispatched events. Turning that into a series of 
action to see if the DOM specs specifies anything in this case and how
 that's handled elsewhere on the platform.

-- 
GitHub Notif of comment by tobie
See https://github.com/w3c/sensors/issues/8#issuecomment-100457371

Received on Saturday, 9 May 2015 09:56:58 UTC