| 03:41 | <MikeSmith> | HTML parsers have to all be taught about the `integrity` attribute? https://bugzilla.mozilla.org/show_bug.cgi?id=1100206 |
| 03:49 | <roc> | MikeSmith: I think that's just an optimization. |
| 03:52 | <MikeSmith> | roc: ah ok |
| 06:15 | <MikeSmith> | hsivonen: minor FYI https://github.com/validator/validator/commit/4fed5654f831bd9b4135cf157997c8413aaededa |
| 06:17 | <MikeSmith> | hsivonen: was doing housekeeping just now (removing executable bit on files per fantasai's e-mail ping) and remembered that VerifierServlet.policy file was still hanging around. Of course feel free to restore it if you actually need it in the repo. |
| 06:24 | <MikeSmith> | hsivonen: another minor housekeeping thing when you have a chance - https://github.com/validator/validator/issues/36 |
| 06:25 | <MikeSmith> | about whether it's ok to `git rm -r research-src` at this point |
| 07:53 | <MikeSmith> | zcorpan: Robin and I may be visiting Lund May 3-4 or May 8-9 |
| 07:53 | <MikeSmith> | but I see now that's not terrifically close to where you are |
| 07:55 | <zcorpan> | MikeSmith: cool. yeah it's 5h car ride |
| 08:42 | <annevk> | JakeA: how realistic is the podcast service worker example if you can't actually fetch episode information from the target domain? |
| 12:57 | <annevk> | wanderview: I'm starting to really like this FetchPromise idea |
| 12:57 | <annevk> | wanderview: currently https://fetch.spec.whatwg.org/#concept-request has some bookkeeping details such as "redirect count" and "response tainting" |
| 12:57 | <annevk> | wanderview: they would fit much better on a "fetch status object" |
| 12:58 | <annevk> | wanderview: could probably also use that to maintain the current URL, rather than mutate request's url as we go... |
| 14:50 | <wanderview> | annevk: sounds good to me |
| 14:51 | <wanderview> | I think its great the promise extension is a feasible approach to take |
| 16:23 | <Domenic> | annevk: what's the plan for cancellation/abort/terminate? Just come up with ad-hoc fetch-only semantics under the name terminate(), then maybe insert CancellablePromise in between the prototype chain later and get a cancel() method? |
| 16:23 | <annevk> | Domenic: that's a plan I had if we don't want to wait for CancelablePromise |
| 16:24 | <Domenic> | yeah, seems OK |
| 16:24 | <annevk> | Domenic: and might make sense given that terminate() is really about terminating the network connection (which also affects the eventual stream) |
| 16:24 | <Domenic> | right, so it would have an effect on fulfilled FetchPromises too |
| 16:25 | <Domenic> | Still unsure whether it should leave the promise forever-pending, or should reject it |
| 16:26 | <annevk> | Domenic: I was going for reject |
| 16:27 | <annevk> | Domenic: that happens when something is wrong with the network now |
| 16:27 | <annevk> | Domenic: also, forever-pending would require a timeout wrapper which seems unfortunate |
| 16:27 | <Domenic> | right. some of the feedback we've gotten on promise-cancellation = rejection has been that that forces people to insert `if (e instanceof Cancellation) { return; }` into the top of every failure handler |
| 16:28 | <Domenic> | I don't follow on the timeout wrapper? |
| 16:28 | <annevk> | Domenic: forever pending means that callbacks are never invoked |
| 16:28 | <annevk> | Domenic: oh, that's interesting |
| 16:29 | <Domenic> | yes, which is often what is desired |
| 16:29 | <annevk> | Domenic: thanks, that makes it indeed not so clear cut |
| 16:29 | <Domenic> | e.g. error handler = show error dialog to user, or do a retry |
| 16:29 | <annevk> | Domenic: what if we offer terminate({rejectWith:...}) |
| 16:30 | <annevk> | when omitted doesn't reject |
| 16:30 | <Domenic> | hmm very interesting |
| 17:30 | <jtcranmer> | any particular reason why fetch() doesn't support some form of aborting a network request? |
| 17:30 | <annevk> | jtcranmer: see logs, not sure about exact API yet |
| 17:32 | <jtcranmer> | ah, so I see |
| 17:32 | <jtcranmer> | tyvm |
| 17:51 | <TabAtkins> | annevk, Domenic: I like the idea of terminating a promise with an option to keep it pending or rejected. Nicely separates out the concerns. |
| 17:52 | <Domenic> | TabAtkins: yeah it is nice and flexible. Trying to think of when I would use the rejectWith option though |
| 17:52 | <TabAtkins> | In a promise combinator? |
| 17:52 | <Domenic> | Hmm yeah maybe |
| 17:54 | <annevk> | Admittedly it is fairly hard to imagine a scenario where network failure and intentionally causing network failure require the same code path |
| 17:54 | <annevk> | So far all I've come up with is showing some generic error message "Your network connections are not up to par!" |
| 18:05 | <jtcranmer> | the use case for terminating network-related promises that is most evident is "user hits the cancel button" |
| 18:05 | <jtcranmer> | potentially there's clean-up related actions |
| 18:06 | <jtcranmer> | but the ultimate .catch() is likely to be some sort of error dialog which you'd want to supress |
| 18:18 | <annevk> | I think another compelling argument for forever-pending is that in the case of the promise already being resolved and the stream being canceled due to lack of network activity you cannot use the promise rejection code path either. |
| 18:26 | annevk | reads through https://github.com/kriskowal/q/issues/64 |
| 18:30 | <annevk> | So Q doesn't have it due to multiple clients of a single promise potentially getting confused |
| 18:33 | annevk | finds https://github.com/promises-aplus/cancellation-spec/issues/6 next |
| 18:33 | <annevk> | I like the uncancellable idea |
| 18:38 | <annevk> | I'm surprised with the double l usage |
| 18:52 | annevk | bugs Kris https://twitter.com/annevk/status/568120153306734592 |
| 18:57 | <jtcranmer> | annevk: fwiw, my motivation towards thinking about cancelling fetch was coming across this monstrosity of a pre-promise code: |
| 18:57 | <jtcranmer> | https://dxr.mozilla.org/comm-central/source/mailnews/base/prefs/content/accountcreation/fetchConfig.js |
| 18:58 | <annevk> | Kris replies! https://github.com/kriskowal/gtor/blob/master/cancelation.md |
| 18:58 | <annevk> | Also https://twitter.com/kriskowal/status/568120887112675328 |
| 18:59 | <annevk> | jtcranmer: heh |
| 18:59 | <jtcranmer> | annevk: if an abortable promise concept were available, I would not have been able to resist the urge to refactor the entire bloody mess |
| 19:00 | <jtcranmer> | well, that and the Fetch API isn't quite implemented in Gecko yet |
| 19:00 | <annevk> | jtcranmer: see dev-platform, we might be shipping in Fx 38 |
| 19:01 | <jtcranmer> | I did see that |
| 19:01 | <jtcranmer> | I was poking at it last night, though |
| 19:01 | <jtcranmer> | but I've got other code using XHR that I'm more minded to switch to Fetch now |
| 19:02 | <jtcranmer> | (assuming Fetch is exposed in JS modules) |
| 20:08 | <aklein> | Hixie: Structured Clone question, you about? |
| 20:10 | <annevk> | aklein: curious |
| 20:10 | <aklein> | annevk: the text of how to set values on objects says "Add a new property to output having the name name, and having the value cloned value." |
| 20:11 | <aklein> | (8.4 of https://html.spec.whatwg.org/multipage/infrastructure.html#internal-structured-cloning-algorithm) |
| 20:11 | <aklein> | I'm guessing that's intended to call [[DefineOwnProperty]] in ES |
| 20:11 | <aklein> | but it would be nice for it to be more explicit |
| 20:11 | <aklein> | (Chrome calls [[Set]], which can cause some surprising behavior) |
| 20:12 | <annevk> | aklein: https://github.com/dslomov-chromium/ecmascript-structured-clone |
| 20:12 | <annevk> | aklein: I recommend continuing to petition TC39 to embrace and extend it |
| 20:12 | <aklein> | annevk: yeah, I agree that that would help |
| 20:13 | <annevk> | aklein: that has [[Set]] but might be due to Chrome doing that, not sure what Firefox does |
| 20:13 | <aklein> | Firefox appears to create own properties |
| 20:13 | <aklein> | don't have anything else handy at the moment |
| 20:13 | <aklein> | HTML already refers to [[Get]] |
| 20:13 | <aklein> | so I don't see any reason why it couldn't use [[DefineOwnProperty]] |
| 20:14 | <aklein> | (or [[Set]], if that's actually intended) |
| 20:14 | <annevk> | aklein: I don't think there's any particular reason, no |
| 20:14 | <annevk> | aklein: might be worth filing a bug, though I would not expect priority to be particularly high |
| 20:15 | <annevk> | aklein: especially with that GitHub repository going on to take it out of HTML |
| 20:15 | <aklein> | I have a meeting tomorrow with dslomov, will ask him if he has background on the status |
| 20:16 | <aklein> | thanks for the pointer to that repo |
| 20:16 | <annevk> | aklein: let me know if he's no longer pushing it, might try to get HTML clarified instead then |
| 20:16 | <aklein> | I know it's not at the top of his priority queue |
| 20:23 | <aklein> | filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28052 |