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