Re: [sensors] Find a better name for 'unconnected' state

Yeah, the use case are described with examples in the [geolocation spec's intro](https://dev.w3.org/geo/api/spec-source.html#introduction). I think having specific methods for this is what makes the most sense, so you can disregard my pushback here.

Following @pozdnyakov's input here, it seems we can try to give an answer to at least some of the questions above. Here are mine with some rationale to them:

1. Are those three states a good model internally (for spec editing)? _**Yes**. I looked at the spec and we don't need more to spec things._
2. Do we want to expose state at all? _I think we can move that decision to **later**. It doesn't seem to be critical to developers right now. Let's expose it once we have use cases._
3. If we want to expose state now, do we expose it as an enum or a boolean "activated" attribute? _We can avoid taking this decision right now and wait for developer feedback before we do._
4. If we expose those externally, what do we name those three states? _Same as above._
5. What do we name the start/stop methods? _I don't have a strong preference, here, but I think we should keep **start/stop**, because they're short and explicit. Moving to activate/deactivate has other problems. Authors would expect the `onactivate` handler to be called in the same turn as activate an called, not asynchronously, when the activation has been carried out._
6. Do we also rename the onactivate handler? _I'd leave it as such unless someone has a better proposition._





-- 
GitHub Notification of comment by tobie
Please view or discuss this issue at https://github.com/w3c/sensors/issues/160#issuecomment-291258297 using your GitHub account

Received on Monday, 3 April 2017 20:07:27 UTC