Max: first, the naming of synchornised and async method. They had a discussion in their WG and it seemed they were unable to reach consensus, that's why they asked us. Two naming proposals. The second part is to ask the TAG to review about the design choices they restrict the sync api to worker only. Rare exception design on the web platform, that's why they want to confirm with us.

Dan: they're really looking for a response on naming in particular..

Max: after looking at WG discussions, maybe first naming is more suitable. They summarized: in the future the api will be async so it's not necessary to .. the default behaviour should be async in the future. So the first..

Dan: Sangwhan should also weigh in. Could you have that discussion with Sangwhan to get feedback, then if you have consensus you could leave that comment.

[come back to this at plenary]

Max: Sangwhan says he has comments but hasn't responded yet. Will follow up.

Hadley: hopefully Sangwhan can respond before plenary

Sangwhan: they want us to choose option 1 or 2, and i'm not sure about either. 1 is all async, and 2 is sync and add async as a suffix. both are ugly. if it's inevitable in the platform, we should have a principle for it. Seems there is an implementation detail here being unnecessarily exposed to the user. imagine you locked everything down to be sync or async.. you'd have to change the paradigm. I wanted to ask domenec, but I feel like both approaches are not great. If you think about making an asyc message sync, there is a semantic for that already. I'm sure they considered it.

what do others think about putting sync or async at the end of every API call?

Amy: why is the wg asking the TAG?

Sangwhan: they couldn't come to consensus

Amy: have they shared their minutes where they show their thinking?

Sangwhan: I read some....

Amy: I suppose a TAG perspective would be about consistency on the web platform?

Sangwhan: there is nothing to be consistent with.

Amy: so it would be setting a precedent

Yves: we usually try to move away from sync calls. Better for performance.

Sangwhan: yes. if we had to chose, it would be asyc by default and sync by exception. but do we want these patterns?

Yves: TC39 might have a voice?

hadley: what's the best way to take this forward? a call with them? including tc39?

sangwhan: we lost our TC39 liaison, so i'm going to message Dan Eranberg to see what we can do. https://cryptpad.w3ctag.org/code/#/2/code/edit/XbFesGNiFynT3ReFOoiiYEIN/ hadley: okay, then do you want to pick a time with breakout C for that call?

sangwhan: may be us/APAC. if it's the same liaison. Let me check with times and see what we can do.

But given that there is an await semantic, i feel like putting it into the API naming is not great. if we're going to do it, we should write a principle about it.

Both seem to be ugly. Not sure what others think.

Yves: it's not nice, but it may be the less evil of all the things.

sangwhan: there is a gap, in await, that we're missing that should probably be addressed. rather than stick sync on everything.

yves: that's why it's better to bring in TC39.

hadley: so when we do have this call with TC39 and the authors, that will be the same question?

sangwhan: semantically, xsync() vs await x should semantically be similar things but there is clearly a gap here.

Sangwhan: I'll report back on who should be involved, and will make this call happen.

Sangwhan: there is work in ECMA to make this less terrible. One year out until we can use it. Asking to follow that pattern they will have to wait a year to ship. Async by default and sync as explicit will be the less terible default. That should be the recommendation we push for. It would be nice if things could be done in an idiomatic way. I will also draft a principles section on how to deal with this - and also note that once there is an idiomatic pattern in place then consider following that patttern.

Sangwhan: files issue in design principles

Dan: would this be a temporary design principle until TC39 bakes this into js?

Sangwhan: correct. Might be longer than temporary. So feedback on this issue is to recommend the less terrible option.

Dan: bump to plenary

Amy: they have this issue about naming

Dan: no new information. Will ask Sangwhan.