| 03:47 | <mnot1> | annvk — looking at URL spec |
| 03:47 | <mnot1> | It doesn't appear to account for http://tools.ietf.org/html/rfc6874 |
| 03:48 | <mnot1> | Not sure how common that is, but it is coming out of Apple... |
| 06:12 | <annevk> | jgraham: I still have "Subproject commit 8ce47687cbbfff6b249bbaf189f096869286c677-dirty" as a change to tools in web-platform-tests |
| 06:16 | annevk | replied to mnot1 on Twitter |
| 07:39 | <annevk> | In HTTP ABNF, "text", how do you indicate text cannot appear in quoted form? |
| 07:40 | <annevk> | I see, you need quoted-string for that |
| 09:12 | <jgraham> | annevk: You can probably ignore that |
| 09:13 | <annevk> | jgraham: yeah, it seems like it doesn't matter much in terms of getting updates and doing commits, but it's still a bit annoying that it shows up |
| 09:13 | <jgraham> | annevk: Right, it should be possible to make it not say that… I'll investigate |
| 09:32 | <Ms2ger> | jgraham, I believe you need to add *.pyc to the gitignore, if you haven't figured that out yet :) |
| 09:34 | <jgraham> | Ms2ger: Looking at a problem with my servo PR instead :) |
| 10:32 | <jgraham> | OK, added a .gitignore file |
| 11:22 | <annevk> | JakeA: it seems you're making good progress on cancelation with Domenic so unless I hear otherwise I'll just wait on the outcome of your research |
| 11:23 | <annevk> | JakeA: I also tried to reply to all the BackgroundSync things |
| 11:27 | <annevk> | JakeA: I have to say by the way that I have "Background App Refresh" (as Apple calls it) disabled and have advised others with battery problems to do the same. In that light I'm still not really comfortable with the period synchronization feature... |
| 11:29 | <rcombs> | anyone around willing to take a look at an HTTP I-D and comment? https://datatracker.ietf.org/doc/draft-combs-http-indeterminate-range/ |
| 11:56 | <annevk> | rcombs: maybe reuse an existing header to advertise the feature? |
| 11:58 | <rcombs> | annevk: I considered extending Accept-Ranges |
| 11:58 | <rcombs> | annevk: but there's a decent chance that existing implementations just look for the exact string "bytes" in there |
| 12:00 | <annevk> | rcombs: there's Prefer, bunch of client hints headers I believe |
| 12:01 | <annevk> | rcombs: I don't know, just seems like adding a new header for each new thing doesn't really scale |
| 12:03 | <rcombs> | eh, it's not like you pay per header, or like there's a significant performance penalty for parsing a new one over parsing a variant of an existing one |
| 12:04 | <rcombs> | I'd have preferred to have something like `Accept-Ranges: bytes, bytes-indeterminate`, but the existing spec isn't clear on multiple values being allowed for that header |
| 12:07 | <annevk> | rcombs: 1#range-unit seems quite clear |
| 12:10 | <rcombs> | I actually don't know for sure what that syntax means (is that valid (E|A)BNF?), but assuming it means "exactly 1 of <range-unit>", then yeah, that'd be clearly not allowing multiple values |
| 12:12 | <annevk> | rcombs: it means one or more comma-separated values |
| 12:12 | <annevk> | rcombs: it's HTTP ABNF |
| 12:12 | <rcombs> | oh, of course it has its own dialect |
| 12:12 | <rcombs> | that I did not know |
| 12:12 | <annevk> | rcombs: https://tools.ietf.org/html/rfc7230#section-7 |
| 12:13 | <rcombs> | thanks |
| 12:21 | <rcombs> | hmm, libavformat checks if the first 5 characters of the header are "bytes", Chromium checks if the string "bytes" appears at all, WebKit just checks if it's not equal to "none", and Firefox checks if it's exactly equal to "bytes" |
| 12:21 | <rcombs> | that last one is what I was afraid of |
| 12:38 | <annevk> | wow |
| 12:38 | <annevk> | that's pretty terrible |
| 12:38 | <annevk> | it's almost as if the HTTP WG doesn't really test things |
| 12:43 | <annevk> | philipj: do you know the details about MIME types and <audio>, <video>, and <track>? |
| 12:43 | <annevk> | philipj: I want to fill out https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-nosniff? |
| 12:44 | <Ms2ger> | Tests? What's that? |
| 12:45 | <darobin> | HTTP 1.x did great without |
| 12:46 | <rcombs> | if the vast majority of uses of a field have a single value, you can bet at least one implementation will check for that value exactly and fail on all others |
| 12:48 | <rcombs> | or otherwise check it lazily, and just make sure it works with existing servers (or files or implementations or whatever) then assume it's fine |
| 12:48 | <rcombs> | hi I'm rcombs and I'm cynical about tech |
| 12:49 | <Ms2ger> | That's why we have test suites on this side |
| 14:18 | <wanderview> | JakeA: is this how Cache add/addAll/put are supposed to work? it seems confusing to me... https://github.com/slightlyoff/ServiceWorker/issues/665#issuecomment-89216340 |
| 14:56 | <caitp> | hm, jhusain isn't big on fetch either |
| 15:02 | <caitp> | why do the cancellation semantics need to be tied to the promise? why not response objects? |
| 15:10 | <wanderview> | caitp: because you need to be able to cancel before the network headers are available and don't have a Response object yet |
| 15:39 | <annevk> | caitp: too late? |
| 15:43 | <caitp> | fine, fetch.abort(thePromise) then :p |
| 15:43 | <caitp> | but I mean |
| 15:43 | <caitp> | it doesn't solve how you'd encode cancellation and avoid deadlocks |
| 15:43 | <annevk> | Deadlocks? |
| 15:44 | <caitp> | well you wouldn't resolve or reject the promise |
| 15:45 | <annevk> | Oh, with your proposal |
| 15:47 | <bradleymeck> | unlimited pending also causes some odd things since you can't do a finally style cleanup |
| 15:47 | <caitp> | yes, that |
| 15:47 | <caitp> | er, that's the proble |
| 15:47 | <caitp> | m |
| 15:47 | <caitp> | this keyboard is really hard to type on |
| 15:49 | bradleymeck | is still upset that finally is no longer 100% guaranteed in generators |
| 15:54 | <annevk> | bradleymeck: JakeA and Domenic have an idea of making .finally work for cancelable promises |
| 15:54 | <annevk> | bradleymeck: but not .catch, which seems okayish |
| 15:55 | <bradleymeck> | uggggg |
| 15:55 | <bradleymeck> | finally, except not like try catch finally |
| 15:56 | <bradleymeck> | we use finally to cleanup steps in both cases, since we keep pushing cleanup steps as we perform them |
| 15:57 | <bradleymeck> | so if there is an error we would need to always add a .catch to do cleanup? |
| 15:58 | <caitp> | ` |
| 15:58 | <annevk> | bradleymeck: not like that |
| 15:58 | <annevk> | bradleymeck: cancelation would trigger finally only, catch/finally still work per usual otherwise |
| 15:59 | <bradleymeck> | seems sane, as cancelation is closer to return than throw |
| 15:59 | <bradleymeck> | at least we are using .return for cancellation on generators |
| 17:15 | <Domenic> | yeah, that was the inspiration |
| 17:16 | <Domenic> | not sure it's actually workable or ergonomic yet, but seems theoretically sound-ish |
| 17:48 | <Domenic> | JakeA: I think I like the onCancelled-handler-chooses approach. That way you get forever-pending by default but the creator can choose. |
| 17:48 | <Domenic> | JakeA: you *could* even extend it so that .cancel(x) passes x to onCanceled, which would allow .cancel({ rejectWith: e }) if the promise-creator was set up to handle that. |
| 19:24 | <caitp> | does it really make sense to use promises at all for something that is more complicated than a success/error response? |
| 19:29 | <jsbell_gardener> | caitp: if "it" was synchronous, would it make sense as function that returns a value or throws? |
| 19:30 | <caitp> | right, but this is re: fetch |
| 19:30 | <caitp> | there are more possible outcomes and no real synchronous analog |
| 19:31 | <jsbell_gardener> | ah, missed the context above |
| 19:44 | <Domenic> | caitp: I think it does. |
| 19:45 | <Domenic> | caitp: you can think about it in a few ways. One is that a promise is an async extension of "completion values" and there are more completion types than just normal and throw. |
| 19:47 | <caitp> | well jhusain was saying "we escaped the land of errnos and sentinel values for a reason, lets not go back!" well, in addition to other things |
| 19:48 | <caitp> | and with the current promise design, how else would you do it? |
| 20:01 | <Domenic> | You wouldn't use the current promise design, you'd use a cancellable promise design |
| 20:03 | <caitp> | Promise.all([ fetchThing1(), fetchThing2(), fetchThing3() ]).ohWaitIDontNeedTheseWhatNow() |
| 20:03 | <caitp> | it doesn't "really" work |
| 20:04 | <Domenic> | I don't really understand either of those two sentences |
| 20:05 | <caitp> | I mean, if cancellable promises can interact with regular promises, then you can lose the cancelable-ness |
| 20:05 | <Domenic> | for sure, that's kind of explicitly the point |
| 20:05 | <caitp> | which is confusing and notgood |
| 20:05 | <Domenic> | if you downcast to a regular promise you're removing the cancel-ability |
| 20:06 | <Domenic> | Kind of like downcasting from v8::Value to v8::Handle :P |
| 20:07 | <caitp> | I dunno, seems like a lot of headaches waiting to happen |
| 20:08 | <wanderview> | Domenic: do you envision a Promise.allCancellable() that would keep the all() behavior and cancellable type? |
| 20:08 | <Domenic> | wanderview: CancelablePromise.all([...]) |
| 20:08 | <Domenic> | base Promise type should be entirely undisturbed |
| 20:09 | <wanderview> | Domenic: and does that throw if passed a non-cancellable promise or something? |
| 20:09 | <Domenic> | wanderview: nah it just converts them to cancelable promises which a no-op cancelation action |
| 20:09 | <Domenic> | wanderview: similarly to how Promise.all converts non-promises to fulfilled promises |
| 20:10 | <caitp> | I know fetch has shipped and all, but it's young and could probably be unshipped in order to fix the design |
| 20:10 | <wanderview> | Domenic: so as a developer, I would just use CancelablePromise.all() all the time right? why would I ever use Promise.all() any more? |
| 20:10 | <wanderview> | in case someone gave me a cancellable promise |
| 20:11 | <wanderview> | or needed to consume my promise as cancellable |
| 20:11 | <Domenic> | caitp: you really have drunk the kool-aid of that thread ... there's nothing wrong with the fetch design. |
| 20:11 | <Domenic> | wanderview: you would use CancelablePromise.all if you wanted the result to be cancelable. But that's pretty rare. Most of the time you don't want to give people the ability to cancel. |
| 20:12 | <caitp> | i am not really following that thread closely, but we're looking at the design for angular's new http abstraction, and jafar husain brought the points there |
| 20:12 | <Domenic> | ah yes, he is everywhere bad-mouthing other peoples' work. |
| 20:13 | <caitp> | i don't know if he's been impolite about it, but he does raise some good points |
| 20:13 | <Domenic> | i really just disagree with them. he's pretty colored by his observable-philia |
| 20:14 | <Domenic> | sour grapes that the platform includes promises and not observables, is what i've seen |
| 20:14 | <caitp> | i mean, I think the platform does get pretty close to observables with DOM events |
| 20:14 | <caitp> | "pretty" close |
| 20:15 | <JakeA> | Domenic: not sure I like the "perma-hang as a default" idea, especially as a chain can cancel without oncancel being called on any promise |
| 20:15 | <Domenic> | caitp: heh. I mean, they are both vaguely event-like. |
| 20:15 | <JakeA> | I think reject or some third state needs to be default |
| 20:16 | <Domenic> | JakeA: hmm. I think the question is, what is the use case for observing cancellation. |
| 20:16 | <JakeA> | Domenic: cancelling spinners for one |
| 20:16 | <Domenic> | JakeA: if we had better answers for that, we could see if e.g. a .finally version is reasonable |
| 20:17 | <Domenic> | OK, cool, that does sound finally-friendly |
| 20:17 | <Domenic> | doAsyncThing().catch(showError).finally(removeSpinner) |
| 20:18 | <JakeA> | Domenic: agreed |
| 20:18 | <Domenic> | This is gonna be a bitch to spec the backend of :P |
| 20:18 | <caitp> | it's probably not a good idea to have a new class of promise in addition to existing promises |
| 20:19 | <Domenic> | I disagree |
| 20:19 | <Domenic> | JakeA: I think I'll revive promises-unwrapping, update it to the latest spec. Then we can use it as a base for CancelablePromise. |
| 20:20 | <caitp> | no, it's a really bad idea, from a web developer's PoV and from a browser vendor's PoV |
| 20:20 | <Domenic> | I disagree. |
| 20:20 | <wanderview> | Domenic: I guess it just seems weird to me that if you use a legacy library in your Promise chain that does not return CancellablePromise, then you can no longer cancel the source of the chain... |
| 20:21 | <Domenic> | wanderview: yeah but the legacy library produces promises that are not meant to be cancelable |
| 20:21 | <caitp> | why not just propose an extension to the promise api for es7? |
| 20:21 | <Domenic> | caitp: because not all promises should be cancelable. That's a capability leak to make them so. |
| 20:22 | <wanderview> | Domenic: but if the source hasn't finished yet, why does the cancellability of the later processing prevent me from cancelling the source? |
| 20:22 | <caitp> | Domenic, they might not all be cancellable, but "finally" surely makes sense for all promises |
| 20:22 | <Domenic> | caitp: oh, yeah, definitely. That was the plan. |
| 20:23 | <caitp> | if you have a single class, you make life much easier for devs |
| 20:23 | <wanderview> | Domenic: it just seems its going to make it harder to glue different modules in the promise ecosystem together... basically creating separate class of modules |
| 20:23 | <caitp> | if they all have a cancel method which may or may not do anything, you make life easier |
| 20:23 | <Domenic> | wanderview: I think that's intended though. You should explicitly opt-in to cancelability. |
| 20:24 | <Domenic> | caitp: I don't think silent failure like that makes anyone's life easier. |
| 20:24 | <caitp> | where's the silent failure |
| 20:24 | <wanderview> | Domenic: I don't see how that jives with CancellablePromise.all() wrapping non-cancellable promises with a no-op cancel()... if thats safe... just give them all a no-op cancel by default |
| 20:24 | <Domenic> | caitp: canceling something that's not actually cancelable is a logic error. Better to get that error than silently doing nothing. |
| 20:25 | <Domenic> | wanderview: it's a shorthand for CancellablePromise.all(mapIterable(i, x => CancelablePromise.resolve(x))) |
| 20:26 | <Domenic> | wanderview: just like Promise.all is a shorthand for Promise.all(mapIterable(i, x => Promise.resolve(x))) |
| 20:27 | <wanderview> | Domenic: I don't see how that behavior is consistent with your statement "canceling something that's not actually cancelable is a logic error" |
| 20:27 | <wanderview> | but I am probably just bikeshedding at this point |
| 20:27 | wanderview | gets out of the way. |
| 20:28 | <Domenic> | wanderview: I see what you're saying. It's an implicit part of the .all contract that you up-cast though. Whereas it's not an implicit part of the anyValue.anyMethod() contract that you up-cast, IMO. So if anyValue does not have a behavior for anyMethod then it seems better to throw. |
| 20:28 | <Domenic> | I dunno, these kind of things make me want to go back to tokens, but then I see how painful they are to use. |
| 20:29 | <Domenic> | I am 100% sure by this point though that CancelablePromise is much better than Task |
| 20:29 | <wanderview> | Domenic: I guess I would argue there is a net benefit to the ecosystem to providing a single Promise class with a default no-op vs. splitting the ecosystem into separate classes with more strictly defined throw-if-not-really-cancelable policy |
| 20:29 | <caitp> | i think it's worth entertaining the guy's ideas a bit, it's not like he doesn't have a clue about api design |
| 20:29 | <Domenic> | caitp: I've been down that road. |
| 20:30 | <Domenic> | caitp: not my first rodeo with Jafar :) |
| 20:30 | <caitp> | so what is the big selling point for sticking with promises, other than "we already shipped" |
| 20:31 | <Domenic> | they're a good abstraction. maybe not what you're used to if you come from C# and Rx.NET, but for people coming from many other languages, and from JavaScript itself, they're quite suitable. |
| 20:32 | <caitp> | buuuut you admit that you need to invent a new variant of them which actually covers all the use cases |
| 20:32 | <caitp> | which doesn't seem very good |
| 20:32 | <Domenic> | why? why is it bad to extend something that exists instead of creating a whole new paradigm people have to learn and choose between? |
| 20:33 | <Domenic> | sometimes you want an array, sometimes you want a map, sometimes you want a set |
| 20:33 | <caitp> | I think because you're still creating a new paradigm, it's just that people will confuse one for the other inadvertently |
| 20:33 | <Domenic> | Doesn't mean arrays suck and when we "invented" maps/sets that means arrays are not very good |
| 20:33 | <Domenic> | analogy is imprecise since maps/sets are not a superset of arrays ... should have probably used iterables in there somewhere... but you get the idea. |
| 20:34 | <Domenic> | It's OK for multiple different-but-related things, with different powers, to exist to suit different use cases |
| 20:34 | <caitp> | it's closer to the ImmutableMap vs Map discussion |
| 20:34 | <caitp> | if people use ImmutableMap and Map interchangeably, they might have a problem |
| 20:34 | <Domenic> | Sure, that's pretty good, I agree. |
| 20:34 | <wanderview> | to be honest, there seemed many similarities between the Task and CancellablePromise concepts... they both ref counted users, etc |
| 20:35 | <Domenic> | Not quite a superset relation, but the different-but-similar tools for different situations is analogous |
| 20:35 | <Domenic> | wanderview: oh? last I saw tasks refused to be called more than once |
| 20:36 | <wanderview> | Domenic: I'm sure there are differences... but the promise extension being discussed seem closer to the Task thing |
| 20:36 | <Domenic> | wanderview: ah I see, they've changed since proposed at TC39 last week |
| 20:36 | <Domenic> | "proposed" |
| 20:37 | <Domenic> | I agree they seem to have coevolved |
| 20:38 | <Domenic> | The main difference at this point seems to be the C#-style separation between operation and subscription rather than the JavaScript-style both-in-one-object. Jafar is indeed not a fan of the JS style, whether it be for generators, iterators, or promises. |
| 20:38 | <Domenic> | I think if we take his Task thing and adapt it to JS style it does end up being CancelablePromise. |
| 20:38 | <wanderview> | Domenic: maybe just call it something completely different and split the difference :-) Its an Activity! and an Activity is a Promise |
| 20:38 | <Domenic> | haha |
| 20:39 | <Domenic> | haven't heard Activity before, that's fun :) |
| 20:39 | <wanderview> | Domenic: oh... or its a Suggestion which extends Promise... Suggestions can be ignored |
| 20:39 | <Domenic> | ah yes, the promises ecosystem needs more puns, definitely let's do that |
| 20:39 | wanderview | stops "helping". |
| 20:40 | Domenic | is still sad it ended up being "fulfilled" and "rejected" instead of "kept" and "broken" |
| 20:40 | <caitp> | heh |
| 20:40 | <Domenic> | new Promise((keep, break) => { /* oops SyntaxError :( */ }) |
| 20:41 | <JakeA> | It all started with stringify. That was the start of the namepocalypse |
| 20:42 | <wanderview> | its a sad truth that bikeshedding names is more fun than c++ |