BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Sabre//Sabre VObject 4.5.8//EN
CALSCALE:GREGORIAN
LAST-MODIFIED:20230919T113432Z
BEGIN:VTIMEZONE
TZID:Europe/Madrid
BEGIN:STANDARD
DTSTART:20221030T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:STANDARD
DTSTART:20231029T010000
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
END:STANDARD
BEGIN:DAYLIGHT
DTSTART:20230326T010000
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
END:DAYLIGHT
END:VTIMEZONE
BEGIN:VEVENT
UID:477d72e8-6beb-427a-a320-f77e97aca326
DTSTAMP:20230919T113432Z
SUMMARY:`AsyncContext` integration with web APIs
DTSTART;TZID=Europe/Madrid:20230913T121500
DTEND;TZID=Europe/Madrid:20230913T131500
DESCRIPTION:https://www.w3.org/events/meetings/477d72e8-6beb-427a-a320-f77e
 97aca326/\n\n[`AsyncContext`](https://github.com/tc39/proposal-async-conte
 xt/) is a stage 2 TC39 proposal that allows propagating values across an a
 sync execution flow\, much like Node.js's [`AsyncLocalStorage`](https://no
 dejs.org/dist/latest-v20.x/docs/api/async_context.html). However\, when bu
 ilding this capability into the web platform we must consider the integrat
 ion with web APIs – should `setTimeout` propagate the async context from
  the point it is called into the callback? What about event registration?\
 n\n\n\n\n\n\n\nFurthermore\, [Chrome has been working](https://bit.ly/task
 -attribution) on associating script-initiated actions from their causes fu
 rther up the async call stack (tracking a task's attribution)\, which is u
 seful browser-internally to enable metrics and web API improvements that w
 ould not be possible otherwise. Task attribution is the same as propagatin
 g browser-internal values across an async execution flow\, so if we can en
 sure all of the task attribution use cases are covered by `AsyncContext`\,
  the former could be built on top of the latter\, in the specs and in brow
 ser engines.\n\nAgenda\n\n**Chairs:**\nAndreu Botella\, Daniel Ehrenberg\n
 \n**Description:**\n[`AsyncContext`](https://github.com/tc39/proposal-asyn
 c-context/) is a stage 2 TC39 proposal that allows propagating values acro
 ss an async execution flow\, much like Node.js's [`AsyncLocalStorage`](htt
 ps://nodejs.org/dist/latest-v20.x/docs/api/async_context.html). However\, 
 when building this capability into the web platform we must consider the i
 ntegration with web APIs – should `setTimeout` propagate the async conte
 xt from the point it is called into the callback? What about event registr
 ation?\n\n\n\n\n\n\n\nFurthermore\, [Chrome has been working](https://bit.
 ly/task-attribution) on associating script-initiated actions from their ca
 uses further up the async call stack (tracking a task's attribution)\, whi
 ch is useful browser-internally to enable metrics and web API improvements
  that would not be possible otherwise. Task attribution is the same as pro
 pagating browser-internal values across an async execution flow\, so if we
  can ensure all of the task attribution use cases are covered by `AsyncCon
 text`\, the former could be built on top of the latter\, in the specs and 
 in browser engines.\n\n**Goal(s):**\nGet feedback from browser vendors and
  other interested parties as to which web APIs should propagate the async 
 context.\n\n\n**Materials:**\n- [Session proposal on GitHub](https://githu
 b.com/w3c/tpac2023-breakouts/issues/39)
STATUS:CONFIRMED
CREATED:20230905T053853Z
LAST-MODIFIED:20230919T113432Z
SEQUENCE:1
ORGANIZER;CN=W3C Calendar;PARTSTAT=ACCEPTED;ROLE=NON-PARTICIPANT:mailto:nor
 eply@w3.org
LOCATION:Triana - Level -1
CATEGORIES:TPAC 2023,Breakout Sessions
END:VEVENT
END:VCALENDAR