| 00:14 | <MikeSmith> | heh |
| 00:14 | <MikeSmith> | I always like the laziest choice best |
| 00:15 | <MikeSmith> | and whatever the opposite if overengineering is, that’s me |
| 00:15 | <MikeSmith> | well maybe that’s under-engineering that would be not good I guess |
| 00:16 | <MikeSmith> | just-right engineering, like Goldilocks and the three bears |
| 00:17 | <MikeSmith> | anyway I think we right-engineered the hell out of this one |
| 00:18 | <MikeSmith> | I’m still auditing the output but so far what I’ve seen all looks perfect |
| 00:20 | <MikeSmith> | so I think we can land this very soon |
| 00:21 | <MikeSmith> | but yeah after that clearly the next step is to do caching |
| 00:22 | <MikeSmith> | I would imagine it’s possible that could be done just by having the highlight server send the right caching headers |
| 00:53 | <jungkees> | Domenic: does it make sense for a task running in a worker event loop to queue a task to a browsing context's event loop without going in parallel? |
| 00:53 | <jungkees> | Domenic: I'm looking at https://w3c.github.io/ServiceWorker/v1/#dom-windowclient-focus |
| 00:54 | <jungkees> | Domenic: There it runs in parallel in the step 3 and it queues a task to the browsing context's event loop from its substeps |
| 00:55 | <jungkees> | I'm curious if I can just queue a task directly to the browsing context without going in parallel there |
| 01:20 | <Domenic> | jungkees: yeah, that makes sense. Good exception to the general rule. |
| 01:21 | <Domenic> | jungkees: I guess the "wait for task to be executed" is the part that needs to be in paralllel |
| 01:40 | <jungkees> | Domenic: that's right. That bit has to wait for the queued task to finish, in parallel, and then I think I need to make it queue another task to the original worker thread to Create Window Client there |
| 01:44 | <jungkees> | Domenic: Or can I even just queue a task to the browsing context and "Wait for task to have executed, in parallel", and then just run the rest of the steps assuming they are still in the original worker's even loop? |
| 01:44 | <jungkees> | Domenic: is that what you meant? |
| 01:49 | <jungkees> | Domenic: that'd conceptually sound like *await* ;). Queuing a new task from steps in parallel sounds like more accurate way to make it I guess |
| 01:53 | <Domenic> | Yeah, I think queuing a new task is a bit better |
| 02:05 | <annevk> | jungkees: why not queue a task from the queued task? Seems simpler than “waiting” for it |
| 13:03 | <Ms2ger> | Q for WebIDL people: is https://heycam.github.io/webidl/#create-an-interface-object ever explicitly called? |
| 14:58 | <Domenic> | Ms2ger: I don't think so. There's a lot of "create the X" algorithms that eventually we hope to tie into a big old "create a realm" algorithm. But right now we are mid-refactoring from declarative "X must exist" to "to create an X" |
| 14:59 | <Ms2ger> | Domenic, ok, thank |
| 14:59 | <Ms2ger> | -s |
| 18:10 | <annevk> | M2ger |
| 18:23 | <wanderview> | annevk: so what happens if a SharedArrayBuffer is transferred via postMessage() from a window to a ServiceWorker? if window and ServiceWorker are in different agent clusters... |
| 18:24 | <Mek> | I think you're supposed to get a onmessageerror event |
| 18:24 | <wanderview> | hmm, ok |
| 18:25 | <wanderview> | and where does it say ServiceWorker is in a different agent cluster? |
| 18:25 | <Mek> | in the definition of agent clusters... let me find the spot... |
| 18:25 | <Mek> | https://html.spec.whatwg.org/multipage/webappapis.html#integration-with-the-javascript-agent-cluster-formalism |
| 18:25 | <wanderview> | Mek: isn't agent cluster in the es spec? I didn't think it talked about DOM things |
| 18:26 | <Mek> | the concept is in the ES spec, but the actual equivalence relation is in the html spec |
| 18:26 | <wanderview> | oh, I see |
| 18:26 | <wanderview> | Mek: thanks! |
| 18:29 | <wanderview> | ok... so dedicated workers seem like the only thing that can share memory |
| 18:29 | <wanderview> | I guess that makes sense |
| 18:29 | <Mek> | and all windows in the same unit of related similar origin browsing contexts |
| 18:29 | <Mek> | (as those are all the same agent) |
| 18:36 | <wanderview> | yea |
| 18:58 | <annevk> | Thanks Mek 😊 |
| 19:04 | <wanderview> | sorry for my confusion |
| 19:12 | <annevk> | No worries |
| 19:12 | <annevk> | This is rather new too |
| 19:18 | <wanderview> | well, its nice that its a new thing for a change... usually its ancient legacy web behavior that I'm shocked to discover |
| 19:20 | <annevk> | Give it ten years |
| 21:59 | <jungkees> | annevk: that was my original thought: queue a task from the queued task. I think that sounds good |
| 22:03 | <annevk> | jungkees: seems less complicated too |
| 22:05 | <jungkees> | annevk: Yes. Although the implementations may have some more async calls between the worker and the browsing context event loop, spec'ing it in that way (without parallel steps involved) sounds simpler |