14:59:34 RRSAgent has joined #wintercg 14:59:38 logging to https://www.w3.org/2024/09/25-wintercg-irc 14:59:38 RRSAgent, do not leave 14:59:39 RRSAgent, make logs public 14:59:40 Meeting: WinterCG 14:59:40 Chair: Andreu Botella 14:59:40 Agenda: https://github.com/w3c/tpac2024-breakouts/issues/76 14:59:40 Zakim has joined #wintercg 14:59:41 Zakim, clear agenda 14:59:41 agenda cleared 14:59:41 Zakim, agenda+ Pick a scribe 14:59:42 agendum 1 added 14:59:42 Zakim, agenda+ Reminders: code of conduct, health policies, recorded session policy 14:59:42 agendum 2 added 14:59:42 Zakim, agenda+ Goal of this session 14:59:43 agendum 3 added 14:59:43 Zakim, agenda+ Discussion 14:59:43 agendum 4 added 14:59:43 Zakim, agenda+ Next steps / where discussion continues 14:59:44 agendum 5 added 14:59:44 tpac-breakout-bot has left #wintercg 22:50:05 andreubotella has joined #wintercg 22:54:44 Willy has joined #wintercg 23:03:42 present+ 23:03:43 gsnedders has joined #wintercg 23:04:11 anssik has joined #wintercg 23:04:33 dom has joined #wintercg 23:04:35 scribe+ 23:04:53 fbedora has joined #wintercg 23:04:56 sisidovski has joined #wintercg 23:05:17 https://people.igalia.com/abotella/pub/TPAC-2024-WinterCG/ 23:05:19 Slides ^ 23:05:31 Slideset: https://people.igalia.com/abotella/pub/TPAC-2024-WinterCG/ 23:05:34 fbedora has left #wintercg 23:05:35 [slide 2] 23:05:59 igarashi has joined #wintercg 23:06:14 present+ Tatsuya_Igarashi 23:06:51 Present+ 23:06:54 [slide 3] 23:07:21 Present+ Anssi_Kostiainen 23:08:27 [slide 5] 23:08:31 RRSAgent, draft minutes 23:08:32 I have made the request to generate https://www.w3.org/2024/09/25-wintercg-minutes.html dom 23:09:42 [slide 6] 23:10:57 [slide 7] 23:13:56 [slide 8] 23:18:21 [slide 9] 23:21:16 [slide 10] 23:21:45 (see https://wicg.github.io/direct-sockets/ ) 23:23:00 [slide 11] 23:24:41 q+ 23:25:27 [slide 12] 23:26:08 q+ 23:27:56 q+ MikeS 23:28:00 q+ Yoav 23:28:23 q+ 23:31:01 dom: 2 points, one with the transition of W3C to Ecma, I think at least there is some good hopes to move forward. more generally speaking we're seeing several spaces where this can be looked at, another area relevant to WinterCG is isolated web apps, you mentioned sockets API, there is a proposal for direct sockets? API which in many ways gets browsers closer to some of the requirements to serverside environments. Theres questions on how do 23:31:01 we maintain convergence for the web, and the questions you were asking there's replies to many of these situations. 23:31:39 andreubotella: curious to hear about the CG transition idea you were suggesting 23:32:42 andreubotella: I'm not familiar with Isolated Web Apps, that sounds worth exploring 23:32:48 ack JaseW 23:33:01 JaseW: moving to ECMA, is this a new committee? 23:33:50 Samina: TGs (technical groups) are under a TC; this makes more sense as a group of its own 23:34:04 s/TC/Technical Committee (TC)/ 23:34:32 Arki: TC53 is doing ES for embedded devices is also independent as a precedent 23:35:23 JaseW: I noticed the CLI API; any chance of looking at unifying a testing API 23:35:29 andreubotella: I don't see why not 23:35:43 s/Arki/Aki 23:36:07 andreubotella: someone would have to come up with a proposal 23:36:08 q+ 23:36:11 ack dom 23:36:14 ack MikeS 23:36:37 MikeS: re working better with upstream - the scariest thing is moneky patching, even when temporary 23:36:51 ... even worse if it gets semi-permanent 23:37:09 ... we wouldn't want to see monkey patching as a basis for a process 23:37:32 ... filing spec issues is the best way to work with upstream, starting from problem description 23:38:00 +1 23:38:38 ... I think we could do this in W3C - not sure the resistance to doing it are necessarily valid; in particular, I think W3C would welcome it 23:39:20 ... I'm not sure I understand the IPR RF commitments issues 23:39:55 ... given that this is listing specs that are already having RF commitments, and is unlikely to need additional commitments 23:40:14 ... most of these features are WHATWG features with a few exceptions 23:41:40 andreubotella: re needing additional commitments, given resistance from W3C members due to that IPR transition 23:42:14 ... re monkey patching, we've moved away from e.g. forking the fetch spec 23:42:27 RRSAgent, draft minutes 23:42:28 I have made the request to generate https://www.w3.org/2024/09/25-wintercg-minutes.html dom 23:43:03 andreubotella: our main concern when contributing to upstream is resistance against adding things that aren't targeting browsers 23:43:13 mikeS: has that happened already? 23:43:45 andreubotella: it isn't that this is getting shut down, but is getting deprioritized if it doesn't affect browsers 23:43:57 ... but you're right we should pursue that path until it gets blocked 23:44:15 mikeS: not getting enough consideration is not limited to this particular space 23:44:29 q? 23:44:33 q+ 23:44:36 q+ mnot 23:45:17 Yoav: there is a spectrum of "badness", forking is worse than monkey patching 23:45:37 martin has joined #wintercg 23:45:38 ... for things that aren't browser problems, what we need is hooks to allow building downstreams specs 23:45:55 ... the main challenge of monkey patching is keeping up downstream with upstream changes 23:46:22 ... We need some high level agreements from WHATWG editors that hooks are OK for non-browser needs 23:46:30 ack Yoav 23:46:56 andreubotella: we might need flags to skip some non-relevant steps 23:47:22 yoav: we want to avoid overcomplexifying the browser specs, but allow downstream specs 23:48:02 anssik: what is your experience with aligning non-browser runtime? do you get disagreements between non-browser runtimes? 23:48:28 andreubotella: we do get some disagreements, e.g. how timeouts get handled 23:49:10 ... part of it is recognizing legacy situations 23:49:38 anssik: is WinterCG the forum where these disagreements are discussed? 23:49:44 sideshowbarker has joined #wintercg 23:49:52 RRSAgent, make minutes 23:49:54 I have made the request to generate https://www.w3.org/2024/09/25-wintercg-minutes.html sideshowbarker 23:50:34 q? 23:50:37 andreubotella: part of is is that each community/project may have different ways of expressing their engine viedws 23:50:39 ack anssik 23:50:47 ack anssik 23:50:51 ack sisidovski 23:51:02 gsnedders has joined #wintercg 23:51:20 sisidovski: many of the engine runtimes are running on the serverworker interface; is there a minimum common Web APi for the ServiceWorker surface itself? 23:51:45 andreubotella: some of the runtimes use directly the ServiceWorker API, some don't 23:52:01 ... it would be interesting if changes to the serviceworker API could affect runtimes 23:52:17 ... one of the things we're starting to look at is to define a server handler function for that 23:52:24 ... it might be interesting to work with SW on that 23:52:28 ack gsnedders 23:52:29 ack gsnedders 23:53:21 gsnedders: you mentioned feeling blown off when filing issues upstream: how much was that getting "we don't care" responses, vs not getting people to work on your problem? 23:53:48 ... if the latter, this is likely a mismatch of priorities, not a refusal to see the work done 23:54:11 andreubotella: e.g. the getSetCookie API doesn't have very obvious browser use cases 23:54:25 ... server side runtimes would greatly benefit from it 23:54:56 ... but I had to find a browser use case to justify the addition to the spec instead of the main use case that was driving the work 23:55:07 ... and there are likely cases without justification in browser 23:55:10 s/ser/sers/ 23:55:18 ... and I ended up doing the browser implementation 23:55:32 ... the runtime implementation was seen as not sufficient 23:55:33 q? 23:55:56 q+ 23:56:13 ack mnot 23:56:34 mnot: I don't agree that we can't ask the community to block on the upstream community willingness to move 23:56:51 ... browsers control WHATWG and have strong influence on W3C 23:57:12 ... having a clear high level agreement feels like a useful prerequisite