- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Sat, 09 May 2015 09:56:44 +0000
- To: public-device-apis@w3.org
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