04:52:24 <RRSAgent> RRSAgent has joined #dap
04:52:24 <RRSAgent> logging to https://www.w3.org/2021/10/27-dap-irc
04:55:30 <xfq> present+
04:55:51 <anssik> RRSAgent, draft minutes
04:55:51 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
04:56:00 <xfq> present+ Arnaud_Mandy_Intel
04:56:23 <xfq> RRSAgent, make log public
04:56:29 <xfq> RRSAgent, draft minutes
04:56:31 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html xfq
04:56:46 <xfq> chair: anssik, reillyg
04:57:31 <xfq> present+ Marcos_Caceres
04:57:54 <larsgk> larsgk has joined #dap
04:58:24 <xfq> present+ Juha_Vainio
04:58:52 <xfq> present+ Anssi_Kostiainen
04:59:26 <xfq> present+ Kenneth_Christiansen
05:00:32 <xfq> present+ Matt_Reynolds
05:01:11 <anssik> Regrets+ Lars_Knudsen
05:01:40 <xfq> present+ plh
05:01:57 <xfq> present+ Reilly_Grant
05:02:21 <scheib> present+ Vincent_Scheib
05:02:24 <xfq> present+ tomayac
05:02:35 <xfq> present+ larsgk
05:03:01 <xfq> present+ Rayan_Kanso
05:03:14 <xfq> present+ Raphael_Kubo_da_Costa,
05:04:04 <reillyg> Scribe+ reillyg
05:04:10 <anssik> Scribe+ anssik
05:04:39 <mattreynolds> mattreynolds has joined #dap
05:04:44 <xfq> present+ John
05:04:48 <plh> plh has joined #dap
05:05:27 <xfq> scribe+
05:05:40 <reillyg> reillyg has changed the topic to: Devices and Sensors WG
05:05:55 <kenneth> kenneth has joined #dap
05:05:58 <reillyg> Topic: Introductions
05:06:04 <kenneth> present+ Kenneth_Christiansne
05:06:07 <kenneth> present+ Kenneth_Christiansen
05:06:16 <rayankans> rayankans has joined #dap
05:06:18 <anssik> Topic: Introduction
05:06:19 <xfq> present- Kenneth_Christiansne
05:06:45 <reillyg> RRSAgent, draft minutes
05:06:45 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html reillyg
05:07:06 <reillyg> anssik: Co-chair, welcome.
05:08:47 <reillyg> reillyg: Co-chair, welcome.
05:09:14 <reillyg> xfq: W3C staff, handle administrative work.
05:10:29 <reillyg> arma: Intel, worked on Generic Sensors and will be presenting Compute Pressure API.
05:10:31 <anssik> Meeting: Devices and Sensors WG - TPAC 2021 vF2F Day 1
05:10:42 <anssik> RRSAgent, draft minutes
05:10:42 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
05:10:44 <reillyg> Chair: reillyg, anssik
05:11:14 <xfq> present+ Fuqiao_Xue
05:11:16 <xfq> present- xfq
05:11:51 <plh> present+
05:11:59 <marcosc> present+ Marcos Caceres
05:13:21 <reillyg> Juha: Welcome.
05:13:48 <reillyg> kenneth: Intel, currently working on the Compute Pressure API.
05:13:53 <reillyg> ... Also member of the TAG.
05:14:29 <reillyg> fbeaufort: Google, Web DevRel on device APIs.
05:14:30 <xfq> present+ François_Beaufort
05:14:44 <reillyg> ... Interested in discussing the Screen Wake Lock API.
05:15:13 <reillyg> larsgk: Working in enterprise awareness of hardware integration capabilities.
05:15:16 <xfq> regrets- Lars_Knudsen
05:15:25 <xfq> present+ Lars_Knudsen
05:15:34 <xfq> present- larsgk
05:16:00 <reillyg> RRSAgent, draft minutes
05:16:00 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html reillyg
05:16:48 <Juha> Juha has joined #dap
05:16:59 <reillyg> marcosc: W3C staff, focusing on Screen Wake Lock API. Also Contact Picker API, as joint deliverable with WebApps WG which I co-chair.
05:17:08 <anssik> RRSAgent, draft minutes
05:17:08 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
05:17:27 <reillyg> mattreynolds: Google, work on Device APIs
05:17:38 <reillyg> ... specification editor for WebHID and Gamepad API
05:17:59 <reillyg> rakuco: Intel, working on Screen Wake Lock API and Generic Sensors APIs
05:18:14 <reillyg> ... Helping others at Intel work on specifications and implementations
05:19:19 <reillyg> anssik: Marcos rules the world as editor and implementer of all specifications in all browsers.
05:19:27 <reillyg> ... (Joking.)
05:20:16 <xfq> present+ sudeep
05:20:38 <reillyg> pfh: W3C staff, will give update on rechartering process
05:21:00 <xfq> s/pfh:/plh:/
05:21:13 <reillyg> rayankans: Specification editor for the Contact Picker API.
05:21:45 <reillyg> tomayac: Google, Web DevRel, jack of all trades, master of none.
05:22:11 <reillyg> RRSAgent, draft minutes
05:22:11 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html reillyg
05:22:45 <reillyg> scheib: Google, manager of reillyg and mattreynolds. Cares about device capabilities.
05:25:09 <anssik> Topic: Charter update
05:26:11 <anssik> plh: the charter does not have a decision yet
05:26:30 <anssik> ... we reviewed the charter in July, one objection received at the end of the charter review period
05:26:58 <anssik> ... we had a call on this objection with the objector in Aug and Sep and later in Sep the case was brought to AB/TAG Council
05:27:10 <anssik> ... good news is this case is #1 on the queue
05:27:57 <anssik> ... my latest prediction is AB/TAG is going to decide to take on the case next week and have resolution by the end of November
05:28:40 <anssik> ... Council is not official yet, we're experimenting with it to be prepared for the Director-free W3C
05:29:07 <anssik> ... part of the FO is a rehash of the previous objection, we want to understand how much precedence there is
05:29:32 <anssik> ... thee new APIs to add, we got consensus on one of theme, for two of them we're lacking implementation commitments
05:29:55 <anssik> ... we asked AC reps to go on record about implementation plans
05:29:57 <anssik> q+
05:31:04 <reillyg> ack anssik
05:31:22 <reillyg> anssik: The AC balloting tool is confusing.
05:31:37 <reillyg> plh: I followed up via email.
05:31:43 <anssik> anssik: I think AC reps are busy people and overlooked some details re implementation plans in the AC review
05:32:06 <anssik> plh: security and privacy reviews are another point in the FO
05:32:07 <anssik> q+
05:32:21 <anssik> ack anssik
05:35:19 <anssik> RRSAgent, draft minutes
05:35:19 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
05:36:00 <anssik> anssik: the concrete impact of this delay is we cannot publish new work on TR track
05:36:06 <anssik> plh: that's correct
05:38:52 <scheib> q+
05:39:38 <anssik> ack scheib
05:40:12 <anssik> RRSAgent, draft minutes
05:40:12 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
05:45:39 <anssik> -> https://www.w3.org/2021/06/DASCharter-ac.html [DRAFT] Devices and Sensors Working Group Charter
05:47:21 <xfq> -> https://lists.w3.org/Archives/Public/public-new-work/2021Jul/0011.html Mozilla's comments
05:49:10 <anssik> Topic: Contact Picker API
05:49:41 <anssik> -> https://wicg.github.io/contact-api/spec/ Contact Picker API
05:51:06 <reillyg> rayankans: New privacy-forward approach to the Contact Picker API.
05:51:19 <reillyg> ... Previous attempts and other APIs grant persistent access to all contacts.
05:51:44 <reillyg> ... This web approach allows users to select contact information that is shared to the site as a one-time action.
05:52:13 <reillyg> -> https://tests.peter.sh/contact-api/
05:52:22 <reillyg> tomayac: Implemented behind a flag in Safari.
05:52:25 <anssik> q+
05:52:32 <reillyg> rayankans: Available in Chrome on Android.
05:53:09 <reillyg> anssik: How much does the specification talk about UX expectations for the picker? How different are the Chrome and Safari implementations?
05:53:25 <reillyg> rayankans: The specification only makes requirements about security & privacy.
05:53:28 <reillyg> ... Origin must be shown.
05:53:39 <reillyg> ... Selection of information must be presented to the user.
05:54:57 <reillyg> anssik: In general specifications stay away from proscribing UX. This specification seems to be innovating in UI. Curious how Safari compares to Chrome.
05:55:53 <reillyg> tomayac: Safari implementation doesn't seem to allow the user to opt out of sharing particular requested fields as the Chrome implementation does.
05:56:30 <reillyg> rayankans: Safari doesn't implement support for addresses and icons at the moment.
05:56:45 <reillyg> ... The API is only available on mobile.
05:57:04 <reillyg> anssik: Marcos, what do you think this API did differently to get acceptance?
05:57:30 <reillyg> marcosc: This seems very similar (also a picker UI). Might be right place / right time.
05:57:41 <reillyg> ... Filtering mechanism might not have been in the original version.
05:58:38 <anssik> -> https://www.w3.org/TR/2011/WD-contacts-api-20110616/ Contacts API (deprecated, for historical reference only)
06:01:52 <reillyg> ... Even though the functionality is similar the new API is vastly improved in terms of API shape.
06:02:58 <reillyg> ... Rayan, what challenges do you see moving forward on an API level?
06:03:14 <reillyg> rayankans: How will this work on desktop?
06:03:24 <reillyg> ... This is designed to be extensible.
06:03:50 <reillyg> How well with this handle addresses? Currently based on how Payments API handles addresses.
06:04:04 <reillyg> ... How well with this handle addresses? Currently based on how Payments API handles addresses.
06:04:24 <reillyg> ... There is a feature request for adding contacts but we don't plan to look into that.
06:04:41 <marcosc> q+
06:05:02 <anssik> ack anssik
06:05:04 <anssik> ack marcosc
06:05:17 <reillyg> marcosc: Same discussion on address formats in the Web Payments WG.
06:05:36 <reillyg> ... Current design maps well to Contacts API on macOS and seems to work well for Google Pay.
06:06:29 <reillyg> xfq: There have been a lot of discussions around HTML autocomplete attribute and address as well.
06:06:39 <anssik> q?
06:06:41 <xfq> https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill
06:07:55 <reillyg> RRSAgent, draft minutes
06:07:55 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html reillyg
06:16:00 <anssik> Topic: Compute Pressure API
06:16:30 <anssik> [slides shared]
06:17:17 <anssik> kenneth: Google started Compute Pressure effort, we at Intel think we have things like adaptive streaming network-bound
06:17:33 <anssik> ... moving use cases to the client such as face detectione etc. become compute-bound
06:18:12 <anssik> ... deeply interested in this effort, similar goal as to adaptive streaming, ensure great UX
06:18:56 <anssik> ... currently proposal exposes normalized CPU clock speed and utilization
06:19:12 <anssik> ... we're experimenting with a new metrics that are more useful
06:19:41 <anssik> arno: there's an implementation of this on Chromium with Chrome Origin Trial completed
06:20:08 <anssik> ... with that only CPU speed and utilization exposed, using Linux familiar procstats etc.
06:20:36 <anssik> ... we thought we can extract the lower part ("backend") into a reusable library to offer more advanced metrics to better solve real-world use cases
06:20:46 <anssik> ... would also allow easier integration into web engines
06:21:21 <anssik> ... only the metrics are given to the browser, an opportunity is to use this with not just browser but also in other contexts such as Node.js
06:21:54 <anssik> ... have a small demo proof-of-concept
06:23:05 <anssik> [video played displaying gauges for CPU speed, CPU utilization, CPU latency, Render engine utilization]
06:24:17 <anssik> q?
06:24:33 <larsgk> q+
06:24:44 <anssik> ack larsgk
06:25:08 <anssik> Lars: very interested in this, and how to make this more generic, e.g. offload to cloud use cases
06:25:25 <anssik> ... maybe it could be interesting to know the CPU util of the cloud
06:27:20 <marcosc> q+ so you can monitor what load **other** apps/system are putting on the system?
06:27:32 <anssik> q?
06:27:39 <marcosc> q+, to: so you can monitor what load **other** apps/system are putting on the system?
06:27:59 <plh> q+
06:28:09 <xfq> present+ larsgk, marcosc
06:28:15 <xfq> q+ larsgk, marcosc
06:28:20 <anssik> q?
06:28:28 <xfq> present- larsgk, marcosc
06:28:52 <cpn> cpn has joined #dap
06:29:03 <reillyg> q+
06:29:07 <xfq> present+ Chris_Needham
06:29:12 <anssik> lars: use cases is to understand whether to run the workloads on the client or on the cloud
06:29:12 <xfq> ack larsgk
06:30:01 <anssik> ack reillyg
06:30:20 <anssik> ack plh
06:30:23 <reillyg> q+
06:30:44 <anssik> plh: are you monitoring other piece of hardware e.g. neural network accelerators?
06:31:29 <anssik> kenneth: the scope is XPU, whatever hardware is there on the machine, we are not ruling out anything
06:31:31 <anssik> q?
06:31:35 <anssik> ack marcosc
06:31:47 <anssik> marcos: wondering can you monitor the overall system load, not just your app?
06:32:10 <anssik> kenneth: the use case is to allow do the same as native apps today, e.g. Zoom can do that
06:32:26 <anssik> ... bucketing is used to mitigate exposure
06:32:51 <anssik> ... sounds familiar to Battery API, where the web developer and OS are both trying to optimize
06:32:54 <anssik> q?
06:33:46 <anssik> q?
06:34:33 <reillyg> kenneth: Allows applications to avoid pressure in order to maintain better overall system performance.
06:34:50 <reillyg> anssik: Doesn't the OS handle this?
06:35:07 <anssik> kenneth: OS know exactly what the app is doing, can lower priority, even stop the process
06:35:23 <anssik> ... this is a hint an app can utilize to optimize UX
06:35:25 <reillyg> kenneth: The OS doesn't know what your application is doing. The application knows which features it can disabled in order to reduce load gracefully.
06:35:26 <anssik> q?
06:36:07 <sudeep> sudeep has joined #dap
06:36:58 <anssik> q?
06:37:14 <anssik> ack reillyg
06:37:43 <anssik> reillyg: if the user is unlikely to notice start bitcoin mining use case was raised for Idle Detection API too
06:38:30 <sudeep> q+
06:38:43 <anssik> ... detecting malicious usage of JS or compute is an active area of work for browsers
06:39:00 <anssik> ... think ad blockers fighting for the pieces of JS the users don't want to run
06:39:19 <anssik> ... we cannot design a programming language that does not allow doing math people don't want
06:39:37 <anssik> q?
06:40:08 <anssik> ... marcos asked on use cases how native apps are doing this
06:40:12 <reillyg> -> https://lists.webkit.org/pipermail/webkit-dev/2021-May/031853.html
06:40:34 <anssik> ... WebKit position on Compute Pressure was interesting in that it makes a claim this kind of reaction to compute pressure is not the right way
06:41:21 <anssik> ... what specific signals are useful to the developer is a key question I think
06:41:29 <anssik> ... it is interesting data point that developers are using these signals
06:41:48 <anssik> ... also interesting to know WebKit engineers think developers should not use these signals
06:42:14 <anssik> ... some disagreement on what are the best practices, and probably Intel folks are in best position to tell how to best utilize a particular type of chip
06:42:17 <anssik> q?
06:42:29 <anssik> q?
06:42:34 <anssik> ack supeed
06:42:40 <anssik> ack sudeep
06:42:58 <anssik> Present+ Sudeep
06:43:33 <anssik> sudeep: had a breakout on edge computing at TPAC, offloading web worker tasks
06:43:55 <anssik> [edge here not meaning Edge the browser obviously :-)]
06:44:01 <larsgk> q+
06:44:29 <anssik> sudeep: wanted to bring this perspective on edge offload for this API
06:44:40 <anssik> q?
06:44:42 <anssik> ack larsgk
06:45:38 <plh> --> https://en.wikipedia.org/wiki/Simple_Network_Management_Protocol Simple Network Management Protocol
06:45:39 <reillyg> q+
06:45:54 <anssik> lars: I've done some work in SNMP, wondering if there's a connection to this API
06:46:08 <anssik> ack reillyg
06:46:50 <anssik> reilly: the questions are which metrics are the most useful here, interesting are that in the Intel demo Cycles Per Instruction (CPI) is used
06:47:24 <anssik> ... addressing a claim that an app wants to use all the resources if available
06:47:58 <anssik> ... e.g. you don't want the web app to use all available disk space
06:48:02 <anssik> q?
06:48:30 <anssik> ... we should provide the capability to allow web apps implement the best perf they possibly can
06:48:43 <anssik> ... in order to do so you need information on the current system conditions
06:49:02 <marcosc> q+
06:49:03 <anssik> ... maybe OS can do a better job here, maybe more generic pressure signals help
06:49:04 <anssik> q?
06:50:04 <anssik> ack marcosc
06:50:37 <anssik> marcosc: I agree with Reilly, I'm running parallel apps and as a user I don't know who is using and needs more CPU cycles
06:50:43 <marcosc> MC: but how can you know what CPU % is being utilized by your particular app?
06:51:21 <anssik> ... how do you know what % of CPU is used by your app and how much pressure there is
06:51:35 <anssik> q?
06:51:54 <anssik> arno: we are thinking of CPU vs. the whole platform available compute
06:52:11 <anssik> ... thinking of process-based metrics
06:52:43 <anssik> reillyg: suggesting as a next step to get feedback from developers who are using compute pressure signals on other platforms
06:52:59 <anssik> ... build examples apps that make use of this to implement real-world use cases
06:53:28 <anssik> ... show the difference between an app that tries to keep load under control and another that uses as much as possible compute available
06:54:03 <scheib> q+
06:54:31 <anssik> ack scheib
06:54:58 <anssik> scheib: use cases are helpful, I'd suggest there are use cases that have optional workload and in those we see the most benefit
06:55:15 <anssik> ... "nice to have" functionality will be scaled if compute is available
06:55:41 <anssik> ... UA cannot know if something is optional and cannot solve that problem
06:59:17 <anssik> Topic: Screen Wake Lock API
06:59:49 <anssik> -> https://github.com/w3c/screen-wake-lock/issues/129#issuecomment-817151517 Screen brightness mode
07:00:29 <anssik> RRSAgent, draft minutes
07:00:29 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
07:01:00 <reillyg> rakuco: Strong signal from developers that there are use cases for this API.
07:01:17 <reillyg> tomayac: Surprising new use case for video player.
07:01:36 <reillyg> ... Video players already take a screen wake lock.
07:02:14 <reillyg> ... Consider splitting screen brightness from wake lock.
07:02:40 <reillyg> ... Previous use cases: barcode scanning and illumination for camera
07:02:41 <anssik> q?
07:03:22 <reillyg> rakuco: Before Netflix case came up there was clarity that the use case was only for raising the brightness.
07:03:25 <reillyg> q+
07:03:25 <anssik> q+
07:03:51 <reillyg> rakuco: Open questions: Tie this into Screen Wake Lock API?
07:03:57 <reillyg> ... Tie this to fullscreen?
07:04:02 <reillyg> ... Timeout?
07:04:05 <reillyg> ... Permission model?
07:04:09 <reillyg> ... Granularity?
07:04:17 <reillyg> ... How bright is too bright?
07:04:25 <reillyg> ... Should this be supported on non-mobile.
07:05:06 <reillyg> anssik: We should schedule a separate meeting to discuss all of these questions.
07:05:38 <marcosc> q+
07:05:53 <reillyg> ... Re the Netflix use case: Is this a common use case?
07:06:04 <anssik> ack anssik
07:06:08 <anssik> ack reillyg
07:07:22 <anssik> reillyg: I'm a bit unsure about the Netflix use case, is this really something you need an API for or should a browser provide a setting for this, maybe video players should integrate brightness into video controls
07:08:03 <anssik> ... the video playing use case seems different from use cases for which we have consensus on: this video needs to be brighter
07:08:19 <anssik> ... this hint is easier to spec that something for generic control over brightness
07:08:49 <anssik> ... are we building an API for something that already exists somewhere as a setting?
07:09:09 <anssik> ... we can think exposing screen brightness as video controls, maybe a declarative API is not need for that?
07:10:44 <anssik> anssik: Francois can you pull in some Netflix people to understand this use cases in more detail whether e.g. video controls would address this?
07:11:00 <anssik> Francois: on desktop, users do not see native controls but custom controls provided by web sites
07:11:13 <anssik> ... need some API to provide these custom controls
07:12:12 <anssik> q?
07:12:15 <anssik> ack marcosc
07:13:01 <anssik> marcosc: agree with reilly and francois, in particular Netflix use case is interesting and I personally use it a lot, native UI control makes a lot of sense, needs discussion with HTML and Media groups at W3C as a generic thing
07:13:27 <anssik> ... QR code is important use case and needs to addressed
07:14:27 <anssik> reillyg: brightness is system-wide control, while e.g. volume is app specific
07:14:59 <anssik> rafael: like to get help from the group to make progress with these issues
07:17:20 <rakuco> s/rafael/rakuco/
07:17:30 <anssik> people interested in Screen brightness Anssi, Fuqiao, Reilly, Raphael, Francois, Thomas Marcos
07:18:31 <anssik> ACTION anssik to set up a follow-up meeting to discuss Brightness Mode,  participants;  Anssi, Fuqiao, Reilly, Raphael, Francois, Thomas, Marcos, Lars
07:18:37 <tomayac> s/Thomas Marcos/Thomas, Marcos
07:18:38 <anssik> ACTION: anssik to set up a follow-up meeting to discuss Brightness Mode,  participants;  Anssi, Fuqiao, Reilly, Raphael, Francois, Thomas, Marcos, Lars
07:19:06 <anssik> Topic: Idle Detection API
07:19:50 <anssik> reillyg: the update on Idle Detection API since our last meeting, there's a complete spec for this and it went through Origin Trial in Chrome
07:20:11 <anssik> ... working with partners interested in the API, result of the OT was that it worked as intended
07:20:59 <anssik> ... use case, if the user is not using the app on desktop the app cannot know if they should send notifications to the mobile or on the desktop
07:21:22 <anssik> ... not having this API caused a lot of user frustration per partner feedback
07:22:04 <anssik> ... response rate to messages remained the same, users got the messages but not unnecessary notifications
07:22:08 <anssik> q?
07:22:41 <anssik> ... the API is behind a permission prompt, and ongoing work is to try to implement adding fuzziness to the timing of timing events
07:22:56 <anssik> ... this hides global state
07:23:38 <tomayac> q+
07:24:00 <anssik> ... mitigating cross-site vectors is work in progress, standard mitigations for events is to only allow sites visible receive the event
07:24:19 <anssik> ... the point of this API is a site that is not visible to get the event, so we add additional mitigations for that
07:24:20 <anssik> q?
07:24:23 <anssik> ack tomayac
07:24:41 <anssik> tomayac: is there a plan to have this limited to an origin?
07:25:03 <anssik> ... I implemented this for a popular PWA and they do not need all the features of the API, only for their own origin
07:26:20 <anssik> reillyg: my feeling is that since this can be polyfilled, it doesn't seem worthwhile to increase the complexity of the API
07:26:34 <anssik> RRSAgent, draft minutes
07:26:34 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
07:27:17 <anssik> q?
07:27:36 <anssik> tomayac: I agree, brought this up because I heard developer feedback in this regard
07:28:52 <anssik> RRSAgent, draft minutes
07:28:52 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
07:30:40 <anssik> anssik: Intel is interested this API and we are working on alternative backends
07:30:45 <tomayac> Closed https://github.com/WICG/idle-detection/issues/36#issuecomment-952619522
07:33:21 <anssik> anssik: prosing we defer Network Information API to tomorrow, agenda updated accordingly
07:33:27 <anssik> [agreement]
07:36:51 <anssik> anssik: thank you everyone for joining us today, see y'all tomorrow at the same time!
07:36:55 <anssik> RRSAgent, draft minutes
07:36:55 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
07:47:36 <marcosc> marcosc has joined #dap
08:07:27 <marcosc> marcosc has joined #dap
08:23:51 <xfq> xfq has joined #dap
10:16:47 <anssik> Agenda: https://github.com/w3c/devicesensors-wg/issues/47
10:16:49 <anssik> RRSAgent, draft minutes
10:16:49 <RRSAgent> I have made the request to generate https://www.w3.org/2021/10/27-dap-minutes.html anssik
10:46:47 <Zakim> Zakim has left #dap
10:49:47 <marcosc> marcosc has joined #dap
12:50:37 <marcosc> marcosc has joined #dap
14:01:12 <wanming> wanming has joined #dap
14:29:45 <npdoty> npdoty has joined #dap
15:44:30 <wanming> wanming has joined #dap
19:44:11 <marcosc> marcosc has joined #dap