| 10:00 | <annevk> | JakeA: I'm still trying to wrap my head around this cancelation stuff |
| 10:01 | <JakeA> | annevk: what's the blocker? |
| 10:01 | <annevk> | JakeA: basically fetch is some kind of thread, but then there's further threads for the async calls fetch has to do, such as pushing and receiving bytes |
| 10:02 | <annevk> | JakeA: just trying to figure out if we can have some kind of generic framework for this kind of cancelation handling |
| 10:02 | <JakeA> | annevk: I thought we hand-wave through all the threads stuff with "in parallel"? |
| 10:02 | <annevk> | JakeA: navigation in HTML has the same problem where we're really hand-wavy about what cancelation means |
| 10:03 | <annevk> | JakeA: yeah, I really don't like "in parallel" |
| 10:03 | <annevk> | JakeA: I mean, it's better than what we had before, but it leaves many things undefined |
| 10:03 | <JakeA> | annevk: we have "add the following abort steps to signal" which acts as a kinda callback, is that not sufficient? |
| 10:03 | <annevk> | JakeA: not saying any of this is a blocker btw, just trying to figure out what the eventual goal should be |
| 10:04 | <annevk> | JakeA: yeah, I think what you have is probably reasonable for the "subthreads" and stuff |
| 10:05 | <annevk> | JakeA: I think implementers might be a little bit confused though with the usage of JavaScript objects to explain low-level primitives (that's also a problem with how we do streams) |
| 10:05 | <JakeA> | annevk: I tried to treat the signal's abort steps as a callback. You end up changing that callback frequently throughout the life of something like fetch (during the request vs during the response). However, Domenic didn't think that would work well for implementers. |
| 10:05 | <annevk> | JakeA: but maybe that's not a big deal |
| 10:06 | <annevk> | JakeA: wanderview said he'd effectively just use the tests... |
| 10:06 | <JakeA> | annevk: Hmm, yeah, I ran into the same problem when I started trying to figure out how downloads should be spec'd. I was using JS streams for internal things |
| 10:07 | <annevk> | JakeA: the other thing I was wondering about is how much work it would be for you to give a high-level description of the cancelation design |
| 10:07 | <annevk> | JakeA: with enough detail to cover whether signals get copied and such |
| 10:07 | <annevk> | JakeA: effectively a detailed summary of the proposed change |
| 10:08 | <JakeA> | annevk: I can do that. Who's the audience? |
| 10:08 | <annevk> | JakeA: that should make review a little easier and might also help to get everyone on the same page (although I doubt there's much disagreement as engagement is rather low) |
| 10:08 | <annevk> | JakeA: maybe just me and Domenic |
| 10:08 | <annevk> | JakeA: but I suspect also the implementers |
| 10:08 | <JakeA> | annevk: ok, I'll throw that together today |
| 10:08 | <annevk> | JakeA: you could maybe make a blog post out of it later on |
| 10:09 | <annevk> | JakeA: might be nice for blog.whatwg.org |
| 10:09 | <JakeA> | annevk: yeah, once we start landing stuff I want to do an update blog post including a bit of history and the API we landed on, and future plans for observing fetch |
| 10:09 | <JakeA> | yeah, happy to do it for blog.whatwg.org |
| 10:10 | <annevk> | note that DOM landed already |
| 10:10 | <JakeA> | Oh cool! |
| 10:10 | <annevk> | https://dom.spec.whatwg.org/#aborting-ongoing-activities |
| 12:19 | <annevk> | JakeA: I read through all the tests btw and they look good |
| 12:19 | <annevk> | JakeA: my main issue there too was lack of a high-level overview |
| 12:20 | <annevk> | JakeA: but I think if we have spec text and some high-level agreement we can just land it all and get another good review when wanderview et al implement/review things |
| 12:20 | <JakeA> | annevk: I was going to write the overview on the test PR. That ok? |
| 12:20 | <annevk> | JakeA: sure |
| 12:21 | <annevk> | JakeA: let me know if there's something more I can do, I just pinged Domenic in the specification PR |
| 12:38 | <JakeA> | annevk: a tangent, but I scribbled down some ideas for a low-level byte store https://github.com/jakearchibald/byte-storage/blob/master/README.md |
| 12:45 | <annevk> | JakeA: main comments I have is that 1) I'd want to make sure that all existing storage stuff can be layered on top and 2) We should make sure it plays well with boxes if we want to go in that direction |
| 12:47 | <JakeA> | annevk: Yeah, 1 is absolutely my intention, but I don't know if I've achieved that. I think a good test would be showing you can implement sqllite on top of it |
| 12:51 | <annevk> | JakeA: for localStorage you need some kind of "sync await", but I think it's fine for that to exist spec-wise |
| 12:52 | <annevk> | JakeA: and there's a couple of things that go beyond origins that might need something special as well |
| 12:52 | <JakeA> | annevk: like cookies? We could ignore that as legacy? |
| 12:53 | <annevk> | JakeA: yeah; dunno if we could just ignore it, but we probably also don't have to account for it too much |
| 12:54 | <JakeA> | annevk: should we even be speccing idb down to its byte serialisation? |
| 12:54 | <annevk> | JakeA: in part the goal is that these various APIs are rewritten in terms of a shared storage API so it's clear how they relate when it comes to quota and locks and such |
| 12:54 | <annevk> | JakeA: no, some of that needs to be opaque |
| 12:54 | <annevk> | JakeA: but we should say where the bytes go |
| 12:54 | <JakeA> | annevk: yeah, speccing locking definitely makes sense. It might be one of the weak points in my doc |
| 12:55 | <JakeA> | true |
| 12:55 | <annevk> | for now that mostly means what box they end up in I suppose |
| 12:55 | <JakeA> | yeah |
| 12:55 | <annevk> | or if they don't end up in one |
| 14:26 | <majidvp> | smaug: birtles: FYI just filed a bug on Firefox implementation of Event.timeStamp https://bugzilla.mozilla.org/show_bug.cgi?id=1381492 |
| 14:40 | <JakeA> | annevk: Is https://github.com/w3c/web-platform-tests/pull/6484#issuecomment-315775251 useful? |
| 14:56 | <smaug> | majidvp: yup, thanks |
| 15:03 | <annevk> | JakeA: yeah, that looks great |
| 15:03 | <annevk> | JakeA: much more elaborate than I expected 😊 |
| 15:04 | <JakeA> | it helped me to write it all down, I think |
| 15:05 | <annevk> | Gotta go now unfortunately, might try to make some time later but otherwise first thing tomorrow |
| 16:08 | <annevk> | JakeA: reading through it now, I don't see request.body covered |
| 16:08 | <annevk> | JakeA: we don't have the infrastructure to test this scenario, but you could have a request.body and a response.body streaming at the same time and both getting aborted |
| 16:09 | <annevk> | JakeA: what we can test however is that request.body gets aborted (or maybe that's not considered because that's not in the spec yet? I have forgotten the state of request streams) |
| 16:33 | <annevk> | JakeA: looks good apart from that, though I wonder if we need to do extra work to make the service worker thing work |
| 16:36 | <JakeA> | annevk: yeah, I avoided request.body due to a lack of implementation. I think it'd be pretty easy to test, I just wasn't confident my test would be right |
| 16:37 | <annevk> | JakeA: Chrome has a cancelable impl somehow? |
| 16:37 | <JakeA> | I can't remember the conditions around request streams, as in preventing them being consumed up-front |
| 16:37 | <annevk> | JakeA: or that part you tested through console.log or some such? |
| 16:38 | <JakeA> | annevk: I tested for silly mistakes in the current tests using XHR & an awful AbortController & AbortSignal polyfill |
| 16:38 | <annevk> | oh fun |
| 16:39 | <annevk> | JakeA: I guess I'd be okay with postponing request stream tests but we'll need a tracking issue somewhere, prolly against WPT |
| 16:42 | <JakeA> | annevk: agreed. I guess I should just take a stab at the tests and get Domenic to suffer through correcting me |
| 16:43 | <annevk> | JakeA: that'd be great, I'm sure implementers are happy to help debug them too |
| 16:51 | <annevk> | JakeA: also raised a new issue in your byte repo thingy |
| 16:52 | <annevk> | JakeA: for context, Luke works on wasm |
| 18:22 | <JakeA> | annevk: ta! Keen to hear from wasm folks. |
| 19:19 | <smaug> | NavidZ: dsf? |
| 19:20 | <smaug> | and I'm trying to find some old bug related to this |