Skip to content
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

Open
tobie opened this issue Sep 4, 2015 · 7 comments
Open

Sensor.frequency needs to be setable to allow frequency adaptation #63

tobie opened this issue Sep 4, 2015 · 7 comments
Labels
Milestone

Comments

@tobie
Copy link
Member

tobie commented Sep 4, 2015

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.

@anssiko
Copy link
Member

anssiko commented Sep 4, 2015

Can this requirement be generalized to apply to any other properties?

@rwaldron
Copy link
Contributor

rwaldron commented Sep 4, 2015

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.

@tobie
Copy link
Member Author

tobie commented Sep 8, 2015

Thanks for validating this with actual implementer feedback, @rwaldron.

@tobie tobie modified the milestone: Level 1 Oct 16, 2015
@tobie tobie self-assigned this Jan 19, 2016
@tobie tobie added the resolved label Jan 19, 2016
@tobie
Copy link
Member Author

tobie commented Jan 21, 2016

As a sidenote, this probably should be a method returning a promise.

@tobie tobie modified the milestones: Level 2, Level 1 Jan 21, 2016
@alexshalamov
Copy link

@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.

@anssiko
Copy link
Member

anssiko commented Feb 7, 2018

All - I'm hearing this issue should be after all deferred to Level 2. Please let us know if you think otherwise.

@anssiko
Copy link
Member

anssiko commented Feb 21, 2018

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.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants