W3C home > Mailing lists > Public > public-device-apis-log@w3.org > April 2017

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

From: Tobie Langel via GitHub <sysbot+gh@w3.org>
Date: Mon, 03 Apr 2017 20:07:20 +0000
To: public-device-apis-log@w3.org
Message-ID: <issue_comment.created-291258297-1491250039-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.4.0 : Monday, 4 July 2022 12:47:53 UTC