- From: Tobie Langel via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Mar 2017 14:34:22 +0000
- To: public-device-apis-log@w3.org
> Could you share some of the use-cases for option 3? Basically anything that involves storing data for later analysis, or near real time, but on remote servers (e.g. for AI). See notably https://github.com/w3c/sensors/issues/98#issuecomment-279981550. > Giving the problem with knowing which sensors will be used and having sensors appear at runtime, it might make sense to make this less flexible for users, as most users will know before hand what sensors they are going to use during their app live cycle. > > When do you set up the size of the shared memory? I guess we could replace it when adding new sensors and just document that adding new sensors may affect data delivery. This optimization seems not to be worth pursuing from an implementation perspective. > Btw [slightly off topic], something which is not clear from API point of view. Say I want to use a RelativeOrientationSensor and a Magnetometer to calibrate the heading every 15 seconds so save power. Right now it is not clear to me whether I should set the frequency very low for the Magnetometer or turn it on/off every 15. Like will I actually save power from the magnetometer or not? > This will probably stay implementation specific. Setting the magnetometer to a low frequency should be your best bet, here, as it let's the UA/OS optimize when to poll. Might be worth opening a dedicated issue to discuss this further. > If we end up dropping data, it would make sense to send timestamp difference from last delivered reading, plus a sequence number. This is for instance used by the Daydream controller which uses Bluetooth and can lose readings. Can you elaborate a bit on this topic, and also think about how we could represent this in the API? Would it be info at the back of the buffer? A dedicated prop on the object? An event? -- GitHub Notification of comment by tobie Please view or discuss this issue at https://github.com/w3c/sensors/issues/171#issuecomment-288097318 using your GitHub account
Received on Tuesday, 21 March 2017 14:34:28 UTC