| 14:01 | <JakeA> | wanderview: can you remember why we have the concept of reserved clients, rather than just having clients.get(resultingClientId) resolve once the client is real? |
| 14:02 | <wanderview> | JakeA: if the FetchEvent handler wants to postMessage() it... maybe that would deadlock? |
| 14:03 | <wanderview> | but I've paged a lot of the reserved client stuff out at the moment |
| 14:04 | <wanderview> | JakeA: also... wouldn't that still require the concept of a reserved client? I mean, some state must be stored to make the browser delay resolving the get() instead of returning null instead |
| 14:11 | <JakeA> | wanderview: yeah, we'd need some concept internally, but I'm doubting whether we should expose them |
| 14:11 | <JakeA> | wanderview: I'll write up an issue |
| 14:11 | <wanderview> | I guess we at least have one thing to talk about at TPAC |
| 14:11 | <JakeA> | :D |
| 14:12 | <JakeA> | btw I'm going to do my usual sweep through the issues next week |
| 14:21 | <wanderview> | JakeA: maybe n8s has a use case for get(reservedId) |
| 14:21 | <JakeA> | wanderview: will ping him in the issue |
| 14:55 | <JakeA> | wanderview: https://github.com/w3c/ServiceWorker/issues/1216 |
| 19:41 | <wanderview> | JakeA: this makes me very happy (if I am reading chrome behavior correctly): https://github.com/whatwg/fetch/pull/146#issuecomment-339778444 |
| 19:50 | <wanderview> | its nice to be able to easily test edge service workers now |