IRC log of dap on 2019-09-20
Timestamps are in UTC.
- 00:14:42 [RRSAgent]
- RRSAgent has joined #dap
- 00:14:42 [RRSAgent]
- logging to https://www.w3.org/2019/09/20-dap-irc
- 00:14:50 [Zakim]
- Zakim has joined #dap
- 00:14:56 [anssik]
- RRSAgent, make logs public
- 00:15:00 [anssik]
- Meeting: Devices and Sensors F2F Day 2 – 20 September 2019
- 00:15:04 [anssik]
- Chair: Anssi, Reilly
- 00:15:13 [anssik]
- Agenda: https://github.com/w3c/devicesensors-wg/issues/24
- 00:15:18 [anssik]
- Scribe: Reilly
- 00:15:23 [anssik]
- scribeNick: reillyg
- 00:16:38 [reillyg]
- Topic: Agenda
- 00:16:48 [reillyg]
- present+ Reilly_Grant
- 00:16:59 [xfq]
- present+ Fuqiao_Xue
- 00:17:05 [anssik]
- RRSAgent, draft minutes v2
- 00:17:05 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-dap-minutes.html anssik
- 00:17:40 [odejesush]
- present+ Ovidio_Ruiz-Henríquez
- 00:18:01 [anssik]
- Present+ Anssi_Kostiainen, Balazs_Engedy, Ovidio_Ruiz-Henríquez, Reilly_Grant, Rijubrata_Bhaumik, Thomas_Steiner
- 00:18:02 [anssik]
- RRSAgent, draft minutes v2
- 00:18:02 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-dap-minutes.html anssik
- 00:25:14 [yoshiaki_]
- yoshiaki_ has joined #dap
- 00:26:32 [reillyg]
- Tom: I would like to add the one remaining Wake Lock issue to the agenda this morning
- 00:26:54 [reillyg]
- present+ Rijubrata_Bhaumik
- 00:27:24 [reillyg]
- Anssi: Do we want to describe the API change to Wake Lock discussed yesterday?
- 00:27:41 [reillyg]
- Kenneth: Yes.
- 00:28:01 [reillyg]
- Anssi: Any other agenda items?
- 00:28:10 [anssik]
- Present+ Ian_Clelland
- 00:28:32 [reillyg]
- [None heard.]
- 00:29:15 [reillyg]
- Kenneth: Is WebHID under incubation?
- 00:29:21 [reillyg]
- Reilly: Yes, I can talk about it.
- 00:30:24 [xfq]
- Topic: WakeLock.request() returns a promise that never resolves
- 00:30:36 [xfq]
- github: https://github.com/w3c/wake-lock/issues/226
- 00:30:43 [anssik]
- https://github.com/w3c/wake-lock/issues/226
- 00:30:49 [anssik]
- scribeNick: anssik
- 00:31:21 [riju]
- riju has joined #dap
- 00:32:40 [anssik]
- reillyg: #226 is a reaction to earlier API changes to remove WK instances and use single instance of a WakeLock object, minimal API that takes wake lock type and AbortSignal
- 00:33:24 [anssik]
- tom: awaiting a promise that never resolves is an uncommon design pattern
- 00:35:13 [anssik]
- reillyg: API was unintuitive, the issue #226 contains a number of examples of code developers would write and would expect to works based on other promise-using APIs
- 00:36:56 [anssik]
- tom: async/await pattern does not work too
- 00:37:03 [anssik]
- Present+ Flaki
- 00:37:22 [anssik]
- RRSAgent, draft minutes v2
- 00:37:22 [RRSAgent]
- I have made the request to generate https://www.w3.org/2019/09/20-dap-minutes.html anssik
- 00:38:10 [anssik]
- reillyg: the proposed fix was to build a mode intuitive API for developers and it fixes the ergonomics issues enumerated in #226
- 00:38:26 [anssik]
- ... had marcos in the room to speak how to use AbortController the right way
- 00:38:51 [anssik]
- ... AbortController was not the right tool for this task
- 00:39:14 [anssik]
- ... we'd instead use a pattern of an id, similarly to setInterval/setTimeout()
- 00:41:38 [anssik]
- tom: should rename "lockId "into "wakeLockID"
- 00:42:01 [anssik]
- reillyg: updated the proposal in #226
- 00:42:30 [scheib]
- scheib has joined #dap
- 00:42:37 [scheib]
- present+
- 00:43:11 [anssik]
- kenneth: it's not constructible?
- 00:44:00 [anssik]
- reillyg: yes, since it's an attribute on navigator
- 00:47:13 [anssik]
- Topic: System lock use cases
- 00:48:06 [kenneth_]
- kenneth_ has joined #dap
- 00:48:13 [kenneth_]
- present: +KennethChristiansen
- 00:48:29 [anssik]
- tom: use cases do not mention system, Google Maps could be a system use case, turn-by-turn navigation
- 00:48:30 [reillyg]
- present+ Kenneth_Christiansen
- 00:48:41 [anssik]
- ... other use cases are for foreground
- 00:48:58 [tomayac]
- https://w3c-webmob.github.io/wake-lock-use-cases/#google-maps for turn-by-turn navigation
- 00:49:06 [anssik]
- reillyg: question, is there a non-geolocation use case for system wakelock
- 00:49:16 [anssik]
- kenneth: WebNFC could be one such use case
- 00:49:48 [anssik]
- tom: flashing Android devices using WebUSB, make sure flash does not stop using system wake lock
- 00:50:05 [anssik]
- ... the screen might turn off, but system should be active
- 00:50:26 [riju]
- https://w3c-webmob.github.io/wake-lock-use-cases/#keeping-the-system-awake
- 00:50:46 [anssik]
- Flaki: acquire both system and screen locks together?
- 00:50:53 [anssik]
- tom: system implies also screen wake lock
- 00:52:25 [anssik]
- reillyg: are there other system lock use cases beyond background geolocation which has its own privacy implementations, and may or may not be the right solution for that API
- 00:52:58 [anssik]
- ... maybe WebUSB flashing, importing photos, other CPU intensive processing, uploading and downloading
- 00:54:16 [anssik]
- riju: OK Google or Hey Siri as a use case?
- 00:54:28 [anssik]
- reillyg: privacy concerns there
- 00:55:02 [anssik]
- tom: system-level indicator, how that should be specified?
- 00:55:34 [anssik]
- reillyg: implementer guidance only, we cannot mandate a particular UI in specs
- 00:55:59 [anssik]
- Flaki: from end-user POV, prefer if the site keeps my site from sleeping to have a persistent notification for that
- 00:56:08 [scheib]
- Please remind me where agenda link is?
- 00:56:52 [anssik]
- reillyg: my thinking around system lock use cases are around progress
- 00:57:43 [anssik]
- ... it may be useful for implementations to provide progress indication along with its request for system wake lock to be used as a progress so could show a progress bar or some such to the user
- 01:01:09 [anssik]
- Flaki: we want our portable device battery last for the day, allowing some crucial components remain active rather than going to deep sleep mode important; baseline assumption, screen and system wake locks are distinct, maybe these heuristics can be extended, example: "just want to play music via HDMI, nothing more" -- could this be UA heuristics or an explicit API?
- 01:01:48 [anssik]
- reillyg: there's room to improve things like media playback etc. so they can take wake lock
- 01:02:04 [tomayac]
- FirefoxOS wake lock types: https://developer.mozilla.org/en-US/docs/Archive/B2G_OS/API/Navigator/requestWakeLock#Parameters
- 01:02:46 [riju]
- Processing (photos , media), playing music (spotify) in the background using say hdmi may beed system wakelock
- 01:02:58 [riju]
- s/beed/need
- 01:03:00 [anssik]
- reillyg: maybe for WebUSB, we could pass info that this is time-sensitive, cannot let buffer go down
- 01:03:35 [anssik]
- tom: issue here is people can always lie when requesting a wake lock with a reason
- 01:03:59 [anssik]
- FirefoxOS had wake locks types for screen, cpu, wifi
- 01:04:12 [anssik]
- s/wifi/wifi and gps/
- 01:05:30 [yoshiaki]
- yoshiaki has joined #dap
- 01:07:09 [anssik]
- anssik: how much mobile platforms provide such wake lock APIs for native developers?
- 01:07:26 [anssik]
- ... this constrains us what we can do
- 01:07:53 [anssik]
- reillyg: Android has only 4 wake lock types: partial wake lock aka system, screen dim wake lock, screen bright wake lock, full wake lock