freenode :: #whatwg

17 Jul 2017
10:00annevkJakeA: I'm still trying to wrap my head around this cancelation stuff
10:01JakeAannevk: what's the blocker?
10:01annevkJakeA: 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:02annevkJakeA: just trying to figure out if we can have some kind of generic framework for this kind of cancelation handling
10:02JakeAannevk: I thought we hand-wave through all the threads stuff with "in parallel"?
10:02annevkJakeA: navigation in HTML has the same problem where we're really hand-wavy about what cancelation means
10:03annevkJakeA: yeah, I really don't like "in parallel"
10:03annevkJakeA: I mean, it's better than what we had before, but it leaves many things undefined
10:03JakeAannevk: we have "add the following abort steps to signal" which acts as a kinda callback, is that not sufficient?
10:03annevkJakeA: not saying any of this is a blocker btw, just trying to figure out what the eventual goal should be
10:04annevkJakeA: yeah, I think what you have is probably reasonable for the "subthreads" and stuff
10:05annevkJakeA: 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:05JakeAannevk: 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:05annevkJakeA: but maybe that's not a big deal
10:06annevkJakeA: wanderview said he'd effectively just use the tests...
10:06JakeAannevk: 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:07annevkJakeA: 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:07annevkJakeA: with enough detail to cover whether signals get copied and such
10:07annevkJakeA: effectively a detailed summary of the proposed change
10:08JakeAannevk: I can do that. Who's the audience?
10:08annevkJakeA: 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:08annevkJakeA: maybe just me and Domenic
10:08annevkJakeA: but I suspect also the implementers
10:08JakeAannevk: ok, I'll throw that together today
10:08annevkJakeA: you could maybe make a blog post out of it later on
10:09annevkJakeA: might be nice for blog.whatwg.org
10:09JakeAannevk: 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:09JakeAyeah, happy to do it for blog.whatwg.org
10:10annevknote that DOM landed already
10:10JakeAOh cool!
10:10annevkhttps://dom.spec.whatwg.org/#aborting-ongoing-activities
12:19annevkJakeA: I read through all the tests btw and they look good
12:19annevkJakeA: my main issue there too was lack of a high-level overview
12:20annevkJakeA: 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:20JakeAannevk: I was going to write the overview on the test PR. That ok?
12:20annevkJakeA: sure
12:21annevkJakeA: let me know if there's something more I can do, I just pinged Domenic in the specification PR
12:38JakeAannevk: 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:45annevkJakeA: 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:47JakeAannevk: 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:51annevkJakeA: for localStorage you need some kind of "sync await", but I think it's fine for that to exist spec-wise
12:52annevkJakeA: and there's a couple of things that go beyond origins that might need something special as well
12:52JakeAannevk: like cookies? We could ignore that as legacy?
12:53annevkJakeA: yeah; dunno if we could just ignore it, but we probably also don't have to account for it too much
12:54JakeAannevk: should we even be speccing idb down to its byte serialisation?
12:54annevkJakeA: 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:54annevkJakeA: no, some of that needs to be opaque
12:54annevkJakeA: but we should say where the bytes go
12:54JakeAannevk: yeah, speccing locking definitely makes sense. It might be one of the weak points in my doc
12:55JakeAtrue
12:55annevkfor now that mostly means what box they end up in I suppose
12:55JakeAyeah
12:55annevkor if they don't end up in one
14:26majidvpsmaug: birtles: FYI just filed a bug on Firefox implementation of Event.timeStamp https://bugzilla.mozilla.org/show_bug.cgi?id=1381492
14:40JakeAannevk: Is https://github.com/w3c/web-platform-tests/pull/6484#issuecomment-315775251 useful?
14:56smaugmajidvp: yup, thanks
15:03annevkJakeA: yeah, that looks great
15:03annevkJakeA: much more elaborate than I expected
15:04JakeAit helped me to write it all down, I think
15:05annevkGotta go now unfortunately, might try to make some time later but otherwise first thing tomorrow
16:08annevkJakeA: reading through it now, I don't see request.body covered
16:08annevkJakeA: 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:09annevkJakeA: 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:33annevkJakeA: looks good apart from that, though I wonder if we need to do extra work to make the service worker thing work
16:36JakeAannevk: 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:37annevkJakeA: Chrome has a cancelable impl somehow?
16:37JakeAI can't remember the conditions around request streams, as in preventing them being consumed up-front
16:37annevkJakeA: or that part you tested through console.log or some such?
16:38JakeAannevk: I tested for silly mistakes in the current tests using XHR & an awful AbortController & AbortSignal polyfill
16:38annevkoh fun
16:39annevkJakeA: I guess I'd be okay with postponing request stream tests but we'll need a tracking issue somewhere, prolly against WPT
16:42JakeAannevk: agreed. I guess I should just take a stab at the tests and get Domenic to suffer through correcting me
16:43annevkJakeA: that'd be great, I'm sure implementers are happy to help debug them too
16:51annevkJakeA: also raised a new issue in your byte repo thingy
16:52annevkJakeA: for context, Luke works on wasm
18:22JakeAannevk: ta! Keen to hear from wasm folks.
19:19smaugNavidZ: dsf?
19:20smaugand I'm trying to find some old bug related to this
18 Jul 2017
No messages
   
Last message: 8 days and 19 hours ago