Re: [sensors] Add solution for one-shot readings

Re @anssiko's 
[comment](https://github.com/w3c/sensors/issues/88#issuecomment-192972157):

> Just noting the `MessagePort` has this interesting (not very 
intuitive IMO) behaviour:
>
>>... when using `addEventListener()`, the `start()` method must also 
be invoked. When using `onmessage`, the call to `start()` is implied.
>
>Applying that pattern to the solution 1 the call to `start()` would 
be implied with `onreading`. We'd need to `start()` when using 
`addEventListener()` though.

Well I was thinking about having, `read()` implicitly deactivate the 
polling (which is doable as both instantiation and call to `read()` 
would be in the same turn, with the polling steps queued-up for the 
next turn.

Definitely seems like a really bad idea. We shouldn't have side 
effects.

> Seems more clear to require start() for both onreading and 
addEventListener('reading', ...), thus the solutions 1 and 2 should 
actually be the same.

Well, I guess we should just say Solution 1 is dreadful and kill it. 
:)

> I'd probably name the method simply start().

I changed it to `activate()` already, but yeah, `start()` could be 
even better (provided we went down that path).

> Also wondering if there are good use cases for explicit pause() and 
resume() or stop() and how would the solution 1+2 compare with 3 in 
that case.

`pause` and `resume` go well with both. Given the underlying 
implementation, there is no need to distinguish between `stop` and 
`pause`. So you'd probably want to go with: `activate` and 
`deacrivate` for Solution 2 and `pause` and `resume` for Solution 3.


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

Received on Sunday, 6 March 2016 20:40:19 UTC