-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sensor.frequency needs to be setable to allow frequency adaptation #63
Comments
Can this requirement be generalized to apply to any other properties? |
This is definitely important and a hard lesson learned by Johnny-Five—which is currently in the planning process of migrating all sensor component classes to support changing frequency after a sensor instance object has been created. |
Thanks for validating this with actual implementer feedback, @rwaldron. |
As a sidenote, this probably should be a method returning a promise. |
@pozdnyakov This is same issue as #139 , I still think we should split parameters that are mutable during lifecycle of a sensor, frequency is one of such parameters. |
All - I'm hearing this issue should be after all deferred to Level 2. Please let us know if you think otherwise. |
I've heard no concerns since airing the proposal two week ago, so I have made a decision to defer this issue (back) to Level 2. (We will likely revisit this issue when the Geolocation Sensor spec commences to this WG as proposed in the Charter draft. I opened a respective issue for the Geolocation Sensor spec https://github.com/WICG/geolocation-sensor/issues/16 to incubate the idea there meanwhile.) |
Use case here is for example frequency of geo-location sensor for live positioning on a map which needs to be high when a map is zoomed in but can be much lower when the map is zoomed out.
More on this gist.
The text was updated successfully, but these errors were encountered: