| 01:31 | <wanderview> | Domenic: I was reading the webidl commentary in here: https://domenic.github.io/async-local-storage/#storagearea |
| 01:32 | <wanderview> | Domenic: just FYI, gecko does have a webidl-to-js binding today... we used it heavily in fxos for things layered on top of IDB |
| 01:32 | <Domenic> | wanderview: oh, wow, neat, I should probably fix that then |
| 01:33 | <wanderview> | Domenic: today, though, we only have one API (webrtc) using it and there is some talk of removing it: https://bugzilla.mozilla.org/show_bug.cgi?id=1450827 |
| 01:33 | <Domenic> | I'd love to see some output, and compare it to my spare-time hobby project webidl2js. (Well, mostly TimothyGu's project now :) |
| 01:35 | <wanderview> | Domenic: this is the js implementation of the PeerConnection interface: https://searchfox.org/mozilla-central/source/dom/media/PeerConnection.js |
| 01:35 | <wanderview> | Domenic: generated binding code calls into it here: https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/RTCPeerConnectionBinding.cpp#9948 |
| 01:35 | <Domenic> | Oh, I see, it generates C++ bindings that wrap JS on the inside |
| 01:36 | <wanderview> | Domenic: we basically do js->c++->js I believe... comment 0 in bug 1450827 discusses some of that |
| 01:36 | <Domenic> | I was thinking of a strategy that generates JS bindings directly |
| 01:36 | <Domenic> | Yeah comment 0 makes more sense now |
| 01:36 | <Domenic> | Yeah here are the generated bindings https://searchfox.org/mozilla-central/source/__GENERATED__/dom/bindings/RTCPeerConnectionBinding.cpp#6105 |
| 01:37 | <Domenic> | Compare with https://gist.github.com/domenic/1f57ecc0720b3861b58192a67e296e9b |
| 01:37 | <wanderview> | Domenic: FWIW, my initial reaction to using "not webidl" in your proposal is that it would make it harder to implement... today we either expose APIs as an es global in spidermonkey or via webidl... this would require building something new and different |
| 01:37 | <Domenic> | Actually https://gist.github.com/domenic/b5c395e036781173e123 is a better example |
| 01:37 | <Domenic> | Well yeah, this will definitely require something different since it's a module |
| 01:38 | <wanderview> | Domenic: whereas if the proposal just used webidl then it would be straightforward to call into IDB c++ code from the new API's c++ code |
| 01:39 | <wanderview> | just my initial reaction |
| 01:39 | <wanderview> | it would be an easier lift |
| 01:39 | <Domenic> | Sure but it's also easy to call into IDB from JS |
| 01:40 | <Domenic> | Basically the tradeoff I see is: Web IDL + some extensions for modules + some extension for non-magic brand checks => people writing in C++ have it easy, people writing in JS need to create a webidl wrapper generator. No-Web IDL => people writing in JS have it easy, people writing in C++ need more infrastructure. Unclear on how to weigh those relatively. |
| 01:40 | <wanderview> | Domenic: but we don't expose DOM APIs without webidl... I think trying to ask all the browsers to change that would make it harder for browsers to adopt this (at least firefox anyway) |
| 01:41 | <Domenic> | I mean we don't expose any DOM APIs via modules right now |
| 01:41 | <wanderview> | I don't see why modules is a requirement for an async key-val store API |
| 01:41 | <Domenic> | Ah |
| 01:41 | <Domenic> | I will refer you to https://github.com/drufball/layered-apis/blob/master/README.md |
| 01:42 | <wanderview> | Domenic: ah, I'll read that.. I guess thats the more appropriate place to discuss webidl-vs-not-webidl |
| 01:44 | <Domenic> | I don't think webidl vs not-webidl is very important... it's just a specification style thing, modulo the additions we'd have to make to webidl |
| 01:45 | <wanderview> | Domenic: it would still be nice to have a formalized idl language (webidl or not) for a module-based system, though... otherwise aren't we back to different APIs and implementations deviating in subtle ways? |
| 01:45 | <Domenic> | Well, no, there shouldn't be. There's only one way to implement that class definition. |
| 01:46 | <Domenic> | Unlike the streams spec, that class definition isn't just informative... it's normative. |
| 01:46 | <Domenic> | So all the stuff IDL takes care of is just automatic from the semantics of JS class definitions |
| 01:46 | <wanderview> | ah |
| 01:46 | <Domenic> | THis is all very expertimental |
| 01:46 | <Domenic> | But I think it's worth experimenting with |
| 01:47 | <wanderview> | sure |
| 01:47 | <Domenic> | The alternative is basically Web IDL with some fun extended attributes (E.g. [ExposedModule="std:async-local-storage"]), and we might totally go that way in the end. |
| 01:47 | <wanderview> | I guess I was just thinking "maybe finally we can get an async key-val API!"... but this stuff seemed like an extra lift, but now I see this is more of test bed for that extra stuff |
| 01:48 | <Domenic> | Ah yeah, I can see how that'd be a surprise, sorry about that :) |
| 01:48 | <Domenic> | I still think it'll happen! Prototyping this quarter. |
| 01:48 | <wanderview> | np |
| 02:02 | <wanderview> | Domenic: at least it seems we will be shipping modules soon... I was going to say we didn't even have that pre-req |
| 09:50 | <annevk> | > Alternatively, we could give priority to FetchObserver and put the data there. |
| 09:50 | <annevk> | JakeA: my initial impression of that idea is good, as JavaScript doesn't really seem to favor branching on exceptions |
| 09:51 | <JakeA> | annevk: we already have some exception branching with aborting fetch. But yeah, `FetchObserver` would let us express the abort case too |
| 09:52 | <annevk> | Yeah, it's somewhat unfortunate we have many patterns for these things, none of them great |
| 13:58 | <wanderview> | annevk: is there a trick to reviewing spec PR's that let you see the final rendered page? |
| 13:59 | <annevk> | wanderview: there's a Preview and Diff link in the PR OP |
| 13:59 | <wanderview> | annevk: thanks! |
| 13:59 | <wanderview> | annevk: for the fragment thing... we probably need a fix in service workers as well |
| 14:00 | <wanderview> | annevk: so if the FetchEvent.request.url has a fragment, but the respondWith() response does not, then we propagate the request fragment to the response |
| 14:00 | <wanderview> | and deal with fragment collision |
| 14:00 | <annevk> | wanderview: that would be good, yes |
| 14:01 | <annevk> | wanderview: I can follow-up on that tomorrow |
| 14:01 | <annevk> | wanderview: but add a comment please? |
| 14:01 | <wanderview> | sure |
| 14:01 | <wanderview> | annevk: also wondering if there could be any weirdness if a site has old responses in Cache API with fragment stripped... but new responses are preserving fragment |
| 14:02 | <wanderview> | since current Cache API loses the fragment at the disk layer |
| 14:02 | <wanderview> | at least in gecko |
| 14:02 | <annevk> | wanderview: ah yes, we should probably consider again what to do for the Cache API here too |
| 14:03 | <wanderview> | interesting... the prev/next buttons don't work in nightly... but the "j" keyboard shortcut works |
| 14:03 | <wanderview> | in diff mode |
| 14:46 | <annevk> | oh, I've never actually tried using those |
| 14:46 | <wanderview> | annevk: actually... it just seems sometimes it doesn;t work |
| 14:46 | <wanderview> | I dunno |
| 14:46 | <wanderview> | computers suck |
| 14:46 | <wanderview> | please send me hardcopy |
| 14:47 | <annevk> | wanderview: via pigeon or boat? |
| 14:47 | <wanderview> | annevk: we should get one of those pneumatic tubes installed |
| 14:47 | <annevk> | (neither prolly works from here; too far and landlocked) |
| 15:06 | <domfarolino> | There's no (internal) way of checking to see if an element was parser-inserted or inserted via script right? (besides for <script> elements given their parser-inserted flag) |
| 15:06 | <domfarolino> | There' |
| 15:40 | <annevk> | domfarolino: correct |
| 18:08 | <annevk> | wanderview: for https://github.com/w3c/web-platform-tests/pull/10449 did you consider the impl implications? |
| 18:08 | <annevk> | wanderview: of having to eagerly parse Location |
| 18:09 | <annevk> | wanderview: also, I was using async, but there's no examples of how to mix them with promise_test/async_test, so I gave up |
| 18:09 | <wanderview> | annevk: I guess I'm not clear what behavior you are seeing and what you expect it to do instead |
| 18:10 | <annevk> | wanderview: on "./test" I get a server redirect to "x"; which I store for later |
| 18:10 | <annevk> | wanderview: then "/x/" is requested and I reply with the redirect |
| 18:10 | <annevk> | wanderview: the expectation is "./x" but the result in Firefox is "/x/x" |
| 18:11 | <annevk> | wanderview: unfortunately testing that requires a lot of resources and I'm not sure where to place them in all in a way that would not be confusing to readers |
| 18:11 | <annevk> | wanderview: the current setup breaks lint unfortunately |
| 18:12 | <wanderview> | annevk: I'm just not convinced its hitting the FetchEvent handler at all is what I was saying |
| 18:12 | <wanderview> | annevk: since you don't wait for activation before creating the frame |
| 18:12 | <annevk> | wanderview: based on the asserts it's hitting it |
| 18:13 | <annevk> | wanderview: otherwise the first assert would fail |
| 18:13 | <annevk> | wanderview: but I'll add that |
| 18:13 | <wanderview> | annevk: this may be more a necko question if its about how we handle Location headers |
| 18:14 | <wanderview> | annevk: anything we do there is probably legacy and long standing... but I'm not sure |
| 18:15 | <wanderview> | sorry |
| 18:16 | <annevk> | wanderview: sure, but this specific scenario only surfaces with service workers |
| 18:16 | <wanderview> | annevk: does it happen in chrome as well? |
| 18:16 | <annevk> | wanderview: in any event, if you don't have strong feelings I guess that's fine |
| 18:16 | <annevk> | wanderview: I still need to install cacert.pem into macOS (which I think is what Chrome would use) |
| 18:17 | <wanderview> | annevk: I would be in favor of making respondWith(Response.redirect()) function the same as a server based redirect |
| 18:18 | <annevk> | wanderview: well that will always have a resolved URL so that is fine |
| 18:18 | <annevk> | wanderview: I guess this would be different from when you construct a Response with a Location header manually |
| 18:19 | <annevk> | Which seems unfortunate; but it also seems bad that the service worker can subvert the server's intent for redirects, given how special redirects are |
| 18:23 | <annevk> | Anyway, thanks for the feedback so far; I guess I'll try clean this up a bit tomorrow and also test some other browsers and synthetic redirects and such (and make sure all that is still defined correctly) |
| 18:24 | <wanderview> | annevk: btw, an async function example: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/service-workers/service-worker/worker-client-id.https.html#35-55 |
| 18:26 | <annevk> | wanderview: thanks; I wonder how that ends up working; guess I need to study async/await again a bit |
| 18:30 | <annevk> | anyway, this was rather fun to do; hope to play more with service workers from now on |