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