| 00:32 | <Hixie_> | jorendorff: what's a Module Instance Object? |
| 00:32 | <jorendorff> | Hixie_: === a Module Object. |
| 00:32 | <Hixie_> | http://people.mozilla.org/~jorendorff/es6-draft.html#sec-module-exotic-objects ? |
| 00:33 | <jorendorff> | yup |
| 00:33 | <Hixie_> | so, how does JS code create an object that has "all the internal data properties of a Module Instance Object"? |
| 00:33 | <Hixie_> | (context: http://people.mozilla.org/~jorendorff/es6-draft.html#sec-linkdynamicmodules step 1.d) |
| 00:34 | <jorendorff> | Hixie_: the only way to do that is with newModule |
| 00:34 | <Hixie_> | ah, ok |
| 00:38 | <Hixie_> | man, linking is really complicated |
| 00:38 | <SamB> | Hixie_: and you aren't even talking about ELF |
| 00:45 | <Hixie_> | i'm amused that CreateModuleLinkageRecord creates an object, not a record... |
| 00:53 | <Hixie_> | jorendorff: any idea what CreateImportBinding is? |
| 05:26 | zcorpan | found http://lists.w3.org/Archives/Public/public-html-a11y/2014Jun/0115.html |
| 05:29 | <zcorpan> | <img src="logo" alt="W3C" longdesc="data:text/html;charset=utf-8;,%3C!DOCTYPE%20html%3E |
| 05:29 | <zcorpan> | %3Chtml%3E%3Chead%3E%3Ctitle%3EDescription%20of%20the%20W3C%20Logo%3C/title%3E%3C/head%3E |
| 05:29 | <zcorpan> | %3Cbody%3E%3Cp%3EA%20blue%20capital%20letter%20%22W%22%20with%20kerning%20so%20it%20 |
| 05:29 | <zcorpan> | touches%20a%20blue%203%2C%20followed%20by%20a%20black%20shadow%20of%20a%20white%20 |
| 05:29 | <zcorpan> | capital%20letter%20C%20all%20on%20a%20white%20background%3C/body%3E%3C/html%3E"> |
| 05:30 | <SamB> | zcorpan: crazyness! |
| 05:32 | <gsnedders> | Go home, you're drunk. |
| 05:41 | <zcorpan> | http://www.w3.org/TR/2014/CR-html-longdesc-20140812/ also introduces the img.longdesc IDL attribute, in addition to the existing img.longDesc http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#dom-img-longdesc |
| 05:41 | <zcorpan> | good times |
| 07:42 | <annevk> | "If the longdesc document proceeds to CR and beyond, I believe the credibility of this WG will be materially harmed." |
| 07:42 | <Ms2ger> | The HTMLWG? |
| 07:46 | <annevk> | Hixie_: https://github.com/slightlyoff/ServiceWorker/issues/410 can't think of any problems with this offhand |
| 07:47 | <wilhelm_> | What happens if you put <picture><p>your random longdesc text here</p></picture>? |
| 07:48 | wilhelm_ | goes off to actually read the <picture> spec. |
| 07:48 | <annevk> | Hixie_: never mind |
| 09:25 | <zcorpan> | anyone remember if chrome or firefox have ever logged warnings in the console about html parse errors? |
| 09:26 | <zcorpan> | wilhelm_: same as <span><p>your random longdesc text here</p></span> |
| 09:27 | <zcorpan> | hsivonen: ^ |
| 09:27 | <gsnedders> | zcorpan: Firefox never has |
| 09:27 | <gsnedders> | https://bugzilla.mozilla.org/show_bug.cgi?id=878364 |
| 09:28 | <zcorpan> | gsnedders: thx |
| 09:28 | <gsnedders> | I don't think Chrome has either |
| 09:28 | <gsnedders> | jgraham: might know? |
| 09:30 | <jgraham> | I don't think anyone ever has |
| 09:30 | <gsnedders> | Presto did. |
| 09:30 | <zcorpan> | yeah |
| 09:30 | <jgraham> | For which kinds of errors? |
| 09:30 | <Ms2ger> | Firefox points them out in view source |
| 09:30 | <gsnedders> | jgraham: You're the one who should know this! |
| 09:31 | <jgraham> | I remember presto having a link to the validator, but not actual error reporting. Obviously I'm wrong though |
| 09:31 | <zcorpan> | jgraham: i think basically all html parser errors |
| 09:32 | <zcorpan> | like "Doctype declaration has invalid format " |
| 09:32 | <zcorpan> | or "Illegal content before DOCTYPE, or DOCTYPE missing " for about:blank :-) |
| 09:32 | <gsnedders> | I think it was all parse errors, but I'm not really sure. I wasn't really around Lkpg by that point to overhear. |
| 09:34 | <jgraham> | I can't see that with 12.16/Linux |
| 09:34 | <jgraham> | Or the web suddenly fixed all its parse errors |
| 09:36 | <jgraham> | did we stop doing this when the new parser landed? |
| 09:36 | <gsnedders> | did you load the page with the dev tools open? |
| 09:37 | <jgraham> | Yes |
| 09:37 | <jgraham> | I got a lot of CSS errors |
| 09:37 | <zcorpan> | i think you're looking at the wrong console |
| 09:37 | <gsnedders> | oh, it's in opera:config |
| 09:38 | <gsnedders> | opera:config#UserPrefs|ShowHTMLParsingErrors |
| 09:38 | <gsnedders> | IIRC the intention was to have no pref and have it shown when the dev tools were open |
| 09:39 | <jgraham> | I'm not sure that was the intention |
| 09:39 | <jgraham> | But OK, old Opera has it, but not by default |
| 09:51 | <zcorpan> | oh, didn't know i had that pref on (or that it existed) |
| 09:52 | <gsnedders> | I just wondered why I wasn't getting any parse errors and looked in opera:config |
| 10:04 | <JakeA> | annevk: might be pedantic, but the as* methods, some suggest reading the data as a particular format (text, JSON, formData) whilst others return a different view of the raw data (ArrayBuffer, Blob). I guess XHR has the same issue, maybe not worth worrying about. |
| 10:42 | <annevk> | JakeA: you could also see it as bytes, text, JSON, form data, with different types for bytes |
| 10:43 | <annevk> | JakeA: if we ever get a true Unicode string we might add an accessor for that too |
| 10:45 | <jgraham> | (fwiw I believe Rust has a nice convention that as_* methods are zero-cost and things that aren't just returning a different view of the underlying data are not called as_. Something like that might be nice, but I guess the ship sailed) |
| 10:45 | <JakeA> | annevk: yeah, I guess it's readAsJSON vs readIntoBlob |
| 10:46 | <JakeA> | Although the latter suggests you provide a blob to read into |
| 10:48 | <annevk> | I think it's both the same really |
| 10:50 | <smaug____> | does html spec define reusing of Window objects ? |
| 10:51 | <JakeA> | asJSON reads as JSON and returns js obj. asBlob reads as binary and returns Blob. asText reads as UTF8 and returns string. |
| 10:51 | <annevk> | smaug____: there's only reuse of a WindowProxy object |
| 10:51 | <annevk> | smaug____: which is somewhat defined, though the details of WindowProxy leave to be desired |
| 10:58 | <smaug____> | hmm, so there is the initial about:blank right before the new page is loaded |
| 10:58 | <smaug____> | and at least in Gecko the Window is reused |
| 10:58 | <smaug____> | assuming about:blank and the new page are coming from the same domain |
| 11:00 | <annevk> | about:blank is different |
| 11:02 | <annevk> | smaug____: see e.g. this note: "In general, there is a 1-to-1 mapping from the Window object to the Document object. There are two exceptions. First, a Window can be reused for the presentation of a second Document in the same browsing context, such that the mapping is then 1-to-2. This occurs when a browsing context is navigated from the initial about:blank Document to another, with replacement enabled. Second, a Document can end u |
| 11:02 | <annevk> | p being reused for several Window objects when the document.open() method is used, such that the mapping is then many-to-1." |
| 11:04 | <smaug____> | ok, so spec is like Gecko here |
| 11:04 | <smaug____> | ok |
| 11:04 | smaug____ | is just wondering the behavior of .localStorage |
| 11:04 | <smaug____> | in case Window is reused |
| 11:05 | <smaug____> | aha, " Each Document object must have a separate object for its Window's localStorage attribute." |
| 11:13 | gsnedders | looks utterly confused at getting email from jgraham reviewing html5lib stuff |
| 11:13 | <gsnedders> | jgraham: are you ill? :P |
| 11:13 | <jgraham> | gsnedders: who knows! |
| 11:23 | <zcorpan> | did someone define mime type parsing? |
| 11:24 | <zcorpan> | http://mimesniff.spec.whatwg.org/#parsing-a-mime-type ... a lot of red boxes |
| 11:30 | <annevk> | zcorpan: yes :-( |
| 11:36 | <annevk> | zcorpan: care to fix it? |
| 11:36 | <annevk> | zcorpan: there's a bunch of issues there |
| 11:37 | <zcorpan> | maybe. currently looking at behavior of the type attribute in general |
| 11:37 | <zcorpan> | seems like it's a mess even ignoring the issue of mime type parsing |
| 11:40 | <annevk> | yeah, there's a number of problems |
| 11:40 | <annevk> | e.g. with whether or not parameters should block or not, whether it's just string matching |
| 11:41 | <zcorpan> | yep |
| 11:41 | <annevk> | or ASCII case-insensitive string matching |
| 11:41 | <zcorpan> | trim or not |
| 11:41 | <annevk> | <style> and <script> are different I think |
| 11:41 | <zcorpan> | empty string equals absent attribute or not |
| 11:41 | <annevk> | string matching of sorts is the best I think |
| 11:41 | <annevk> | e.g. registry based, no parameters |
| 11:42 | <annevk> | for new attributes |
| 12:43 | <Ms2ger> | gsnedders, maybe relevant: https://twitter.com/csoghoian/status/499402368694616064 |
| 12:53 | <Ms2ger> | Oh, heh |
| 12:54 | <Ms2ger> | I thought WorkerLocation_host.htm would test that the browser supports WorkerLocation.host |
| 12:54 | <Ms2ger> | But it only tests WorkerLocation.host and Location.host both, or neither |
| 12:57 | <Ms2ger> | Hmm |
| 12:59 | <Ms2ger> | Given new Worker("support/WorkerLocation.js?") |
| 12:59 | <Ms2ger> | What is location.search? |
| 12:59 | <Ms2ger> | annevk, ^ |
| 13:04 | <caitp> | don't you discard the search query if they're not used in a relative url, when resolving a relative url? |
| 13:13 | <JakeA> | What's the benefit of sharedWorker.port vs sharedWorker.postMessage and sharedWorker.onmessage? |
| 13:17 | <annevk> | Ms2ger: the spec doesn't say? |
| 13:17 | <annevk> | caitp: nope |
| 13:18 | <annevk> | JakeA: there's no sharedWorker.postMessage |
| 13:18 | <JakeA> | yes |
| 13:18 | <JakeA> | but why? Why was .port a better idea? |
| 13:19 | <caitp> | are you serious? if window.location is `https://foo.com/path/index.html?search=puppies`, and I create a worker with a relative uri `resources/worker.js`, the resolved URI would still contain `?search=puppies`? that seems dumb |
| 13:20 | <annevk> | caitp: oh no, if your relative URL does not contain a query component it won't get one |
| 13:21 | <annevk> | JakeA: good question |
| 13:21 | <caitp> | that makes more sense :> |
| 13:22 | <annevk> | Ms2ger was asking about something else |
| 13:22 | <annevk> | JakeA: I assume it is related to GC |
| 13:22 | <annevk> | JakeA: smaug____ might know and Hixie_ otherwise |
| 13:23 | <JakeA> | Cheers. serviceworker has .postMessage and .onmessage, but maybe there's some reason it should be .port |
| 13:23 | smaug____ | doesn't know. He was against all the ports |
| 13:26 | <jgraham> | Hixie_ had some idea of using ports passed over channels for some kind of object capability system. But I don't know if that's related to this |
| 13:28 | <annevk> | JakeA: it seems like we should have good reasons to diverge from the existing pattern for shared workers since we are copying them mostly |
| 13:29 | <gsnedders> | Ms2ger: only vaguely; doesn't address why they have it at all! |
| 13:29 | <JakeA> | annevk: I don't think we're coping sharedworker all that much. The lifecycle is different is very different |
| 13:29 | <JakeA> | copying* |
| 13:30 | <annevk> | JakeA: well the global inherits from it |
| 13:30 | <annevk> | JakeA: and architecture-wise in browsers there's quite a bit of sharing as I understand it |
| 13:30 | <JakeA> | annevk: We're not inheriting from the global |
| 13:31 | <JakeA> | annevk: We don't want onconnect or name |
| 13:31 | <JakeA> | annevk: I take the point about sharing, but the terminating and spinning up just-in-time is very different to sharedworker |
| 13:33 | <Ms2ger> | annevk, oh, the spec does say, but I guess I misread it when implementing |
| 13:33 | <annevk> | Oh I see |
| 13:33 | <Ms2ger> | annevk, or did it change recently? |
| 13:33 | <annevk> | Ms2ger: define recently |
| 13:33 | <Ms2ger> | annevk, since end of June |
| 13:34 | <annevk> | Ms2ger: there was https://github.com/whatwg/url/commit/f3bd39040ee1a2aabe0863879f2fc74f17c3b0f0 |
| 13:34 | <annevk> | Ms2ger: but that doesn't really affect this |
| 13:34 | <Ms2ger> | No |
| 13:34 | <Ms2ger> | Weird |
| 13:36 | <annevk> | JakeA: I think it would be good to talk the current design through with Hixie_ |
| 13:36 | <annevk> | JakeA: or maybe file bugs on HTML that make API reuse easier |
| 13:36 | <annevk> | JakeA: e.g. service worker not having to define IDL for postMessage or even defining postMessage seems sensible |
| 13:37 | <annevk> | JakeA: and HTML is certainly not fixed |
| 13:37 | Ms2ger | fixes Servo |
| 13:38 | <JakeA> | annevk: we're not defining postMessage at the moment, we're inheriting from Worker to get it |
| 13:38 | <annevk> | JakeA: but Worker has things we don't want |
| 13:38 | <annevk> | JakeA: so coordinating with Hixie_ to get a subset interface would be good |
| 13:39 | <JakeA> | terminate, yeah. Hmm |
| 13:44 | <annevk> | added my suggestion in the issue |
| 13:47 | <annevk> | JakeA: we're planning on adding caches for documents |
| 13:47 | <annevk> | JakeA: but we worry that window.caches might break |
| 13:48 | <JakeA> | annevk: yeah, figured that might be the case |
| 13:48 | <JakeA> | annevk: is it just that it's too short & potentially ambiguous a name? |
| 13:48 | <annevk> | JakeA: mostly that it might clash with existing content in some way |
| 13:49 | <wanderview> | right now I have it behind a pref at window.navigator.caches |
| 13:49 | <annevk> | JakeA: e.g. if someone has <p id=caches> <script> caches.textContent = "global object so bad" </script> |
| 13:50 | <annevk> | (<p id=navigator> <script> navigator.textContent = "global object so bad" </script> fails) |
| 13:51 | <wanderview> | I guess not crucial to get right now as its not spec'd, just wanted to know what we were leaning towards so I could make my prefed-off thing match |
| 13:52 | <annevk> | so fetch() is always on the global at the moment |
| 13:53 | <JakeA> | navigator.caches isn't end of the world. window.resourceCaches is… probably worse |
| 13:53 | <JakeA> | but yeah, fetch has the same issue |
| 13:53 | <annevk> | fetchStore ftw |
| 13:54 | <JakeA> | :sadface: |
| 13:54 | <JakeA> | that was a dark time |
| 13:57 | <wanderview> | annevk: why isn't this a problem for fetch as well? should we move it to window.navigator.fetch? |
| 13:58 | <JakeA> | navigator - the *other* dumping ground |
| 13:59 | <zcorpan_> | just call it XMLHttpFetch |
| 13:59 | <JakeA> | haha |
| 14:00 | <JakeA> | resourceFetch resourceCaches |
| 14:00 | JakeA | is sick in mouth |
| 14:00 | <annevk> | wanderview: the idea was to be bold and brave |
| 14:01 | <annevk> | wanderview: until we move to navigator |
| 14:01 | <annevk> | wanderview: with tail between our legs |
| 14:01 | <annevk> | or some such |
| 14:01 | <wanderview> | I'm not particularly advocating that... just seems like a similarly common word to "caches" |
| 14:02 | <annevk> | I guess we should try putting both on Window and see |
| 14:03 | <wanderview> | ok, I'll stick it on window |
| 14:03 | <wanderview> | behind a pref |
| 14:03 | <wanderview> | in my local patch queue, not committed to any repo |
| 14:06 | <JakeA> | I'm doing a quick search for id="caches" and id="fetch", see how many pages have it |
| 14:07 | <annevk> | JakeA: not sure if that's the only possible problem |
| 14:07 | <annevk> | JakeA: I'm a bit hazy on compat hazards when it comes to adding new things to the global |
| 14:09 | <JakeA> | agreed, it's just a vague indicator |
| 14:10 | <zcorpan_> | view-source:http://fuskator.com uses id="fetch" (site is NSFW) |
| 14:11 | zenparsing | goes and invents a proper module system to supplant the global object, oh wait... : \ |
| 14:12 | <zcorpan_> | didn't find other id=fetch or caches but i didn't let the grep finish |
| 14:13 | <annevk> | bit annoyed with a lot of the module stuff happening in private |
| 14:15 | <zenparsing> | don't get me started annevk : ) |
| 14:22 | <Domenic> | window.fetch -> window.JSONSpdyRequest kthxbai |
| 14:51 | <JakeA> | Domenic: requestPermission - should it reject if permission is denied, or resolve with "false" |
| 14:51 | <Domenic> | JakeA: that naming could go either way, but I think we have historically leaned toward reject |
| 14:51 | <JakeA> | Cheers |
| 15:18 | <annevk> | Domenic: JakeA: https://github.com/slightlyoff/ServiceWorker/issues/413 |
| 15:18 | <JakeA> | already there |
| 15:26 | <annevk> | need streams sorted \o/ |
| 15:38 | <JakeA> | annevk: I'm not following #413. We have request for input, response for output. You can provide a readable stream for the request body. |
| 15:39 | <ehsan> | JakeA: good catch on MessagePort btw |
| 15:40 | <JakeA> | ehsan: I think there's more. Window has postMessage & onmessage too. It loops back, but I don't think that matters |
| 15:41 | <ehsan> | JakeA: ah, yes, Window! |
| 15:41 | <ehsan> | commented on the bug |
| 15:45 | <annevk> | JakeA: request has both input and output |
| 15:45 | <annevk> | JakeA: response has both input and output |
| 15:50 | <Domenic> | It depends on if you're on the server or client, is the way I think about (based on my Node background) |
| 15:50 | <annevk> | foolip: sorry about the fullscreen stuff, obviously my head isn't in it |
| 15:50 | <Domenic> | (I wonder if other HTTP frameworks have similar nomenclature... checking) |
| 15:51 | <annevk> | Perhaps what Request and Response expose should just depend on what side of the fence people are on, but that would make them slightly less generic |
| 15:51 | <Domenic> | Inside the server (service worker) you want both |
| 15:51 | <annevk> | Well, and that wouldn't work if you wanted to pass a Request through |
| 15:51 | <annevk> | Or pass a Response through |
| 15:51 | <annevk> | Right |
| 15:52 | <annevk> | foolip: do you mind that I just keep trying? |
| 16:01 | <Domenic> | getSnapshots()? hmm |
| 16:07 | <annevk> | Domenic: wut? |
| 16:07 | <annevk> | fricking Twitter, overrides CMD+T |
| 16:10 | <caitp> | >> can't reproduce |
| 16:13 | <annevk> | Domenic: read and write instead of input and output? |
| 16:14 | <kriskowal> | in my experience, you only need readable “body” streams for both requests and responses |
| 16:15 | <kriskowal> | uploading is a matter of constructing a readable stream that will produce the upload on demand |
| 16:15 | <JakeA> | kriskowal: like https://github.com/slightlyoff/ServiceWorker/issues/413#issuecomment-52071152? |
| 16:15 | <Domenic> | yes, you can design a stream system where there is nothing to represent things you write to |
| 16:16 | <Domenic> | besides functions that accept readable streams |
| 16:17 | <kriskowal> | though if you *want* to write with a producer style, you can always use a buffer, generate on the in side, vend the output as the request body |
| 16:18 | <Domenic> | yes, the point of designing a writable stream abstraction is so that nobody has to write their own buffering code |
| 16:18 | <JakeA> | Domenic: could make Request.streamed(url, opts, function(inputStream) { }) which returns a Request |
| 16:18 | <JakeA> | and Response.streamed that does the same but for response |
| 16:20 | <Domenic> | I don't understand what those do |
| 16:21 | <JakeA> | You write/pipe to inputStream, it comes out of the .body stream |
| 16:21 | <kriskowal> | i wrote a sketch of an object buffer the other day, http://kriskowal.github.io/gtor/docs/promise-buffer.html |
| 16:22 | <kriskowal> | still working on a byte buffer with the same interface |
| 16:22 | <Domenic> | The thing is, there is an actual writable socket underlying the HTTP request body. You want to expose that as directly as possible. |
| 16:23 | <kriskowal> | I think that’s a dubious assumption. |
| 16:24 | <kriskowal> | I mean, clearly there are people that do want that, but I am not sure it is good for them. |
| 16:25 | <kriskowal> | There’s a tension between having applications factor nicely and being able to squeeze that last milisecond out of the system. |
| 16:25 | <kriskowal> | If you expose the request as a writable stream, you necessarily end up with Node.js/Connect style applications, with request and response arguments |
| 16:26 | <kriskowal> | and of course it’s trivial to construct a Promise CGI-like abstraction atop that foundation |
| 16:30 | <kriskowal> | and vice versa |
| 16:31 | <Domenic> | annevk: req.body.read.read()/req.body.write.write()? |
| 16:32 | <annevk> | amazing |
| 16:33 | <annevk> | kriskowal: what you're saying sounds much more like what I'd like to see |
| 16:33 | <annevk> | given how high-level promises can be, why can't streams |
| 16:35 | <kriskowal> | i have about a month to do whatever i want, so i’ve been writing and article on the subject, with code sketches |
| 16:35 | <JakeA> | I really think the writable stream of a request should be revealed by constructor function like resolve/reject in promises |
| 16:35 | <kriskowal> | i just got it to the point that there aren’t any todo comments, but a lot of further work intended… |
| 16:35 | <kriskowal> | been hoping it would be useful in this context https://github.com/kriskowal/gtor/blob/master/README.md |
| 16:35 | <Domenic> | JakeA: why not make it public? |
| 16:36 | <kriskowal> | async generators are going to look like the revealing constructor pattern |
| 16:36 | <Domenic> | JakeA: it's an interesting idea |
| 16:36 | <annevk> | kriskowal: cool, will try to read that later (evening here) |
| 16:36 | <JakeA> | Isn't the writable stream of the request for the creator of the request? |
| 16:37 | <Domenic> | Yeah, now that I think about it, that's probably true, isn't it... |
| 16:37 | <annevk> | makes sense, true for response too |
| 16:37 | <kriskowal> | body: async *function () { await yield chunk; await yield chunk; await yield chunk; } |
| 16:38 | <kriskowal> | i suspect that those awaits should be implicit, but not sure. |
| 16:38 | <annevk> | kriskowal: you have some plan for feeding the whole thing back into TC39? |
| 16:39 | <Domenic> | so /* client*/ new Request(url, { method: "POST", streamer(body => { readableSource.pipeTo(body); }) }) |
| 16:39 | <kriskowal> | the revealing constructor would look like new PromiseIterator(function (doyield, doawait, doreturn, dothrow) {}) |
| 16:39 | <annevk> | kriskowal: Mark? |
| 16:39 | <JakeA> | In the current design you could provide a null transform stream as the body of the request, but a factory method could make that easier |
| 16:39 | <Domenic> | streamer needs a better name |
| 16:39 | <Domenic> | I don't see the factory method thing |
| 16:39 | <Domenic> | Just the constructor seems fine |
| 16:39 | <kriskowal> | annevk: not sure what you’re asking |
| 16:40 | <JakeA> | Domenic: you're a fan of overloading right? We've already got a body option that can take a stream, blob, string etc, it could take a function |
| 16:40 | <annevk> | kriskowal: TC39 is reportedly working on async generators |
| 16:41 | <Domenic> | ;_; |
| 16:41 | <JakeA> | (I don't know if I'm serious or not) |
| 16:42 | <Domenic> | It does solve the "what if I put body and streamer in the same object" problem... |
| 16:42 | <kriskowal> | JakeA: bad smell here |
| 16:42 | JakeA | wafts |
| 16:42 | <Domenic> | if we had a better name for streamer I would feel better refuting the overload |
| 16:42 | <kriskowal> | annevk: yeah, Domenic informed me that they are asking questions about async generators. i think they’re on the right track based on reading the presentation, and you’ll see what i think in that paper i linked |
| 16:44 | <Domenic> | streamer reminds me of https://twitter.com/ChromerShow |
| 16:45 | <kriskowal> | tell me again what streamer does? |
| 16:47 | <Domenic> | it gives you access to the writable side of the body stream |
| 16:50 | <kriskowal> | so, you know how we fought hard to make sure all the promise libs split the promsie and resolver? |
| 16:51 | <kriskowal> | so that you could pass the observer capability without implicitly passing the resolver capability |
| 16:51 | <kriskowal> | this is a situation where the same design pattern applies |
| 16:52 | <kriskowal> | the input is the resolver, the output is the observer |
| 16:52 | <kriskowal> | but it sort-of doesn’t apply because streams are cooperative and information necessarily flows both directions for congestion control purposes |
| 16:52 | <kriskowal> | and because streams are cancelable |
| 16:53 | <kriskowal> | for that reason, it *might* be acceptable for the tangled pair to expose input.output and output.input |
| 16:54 | <kriskowal> | and i could see a generator/writer having a method like streamer. i’ll think about the name. |
| 16:56 | <JakeA> | kriskowal: the streamer option is only settable on construct. You give it a function that's called back with the writable stream |
| 16:56 | <JakeA> | So it's very much like promises |
| 16:56 | kriskowal | looks at the syntax |
| 16:57 | <JakeA> | new Request(url, { streamer: function(writableStream){...} }) |
| 16:59 | <kriskowal> | to be exactly analogous to a promise… |
| 17:00 | <kriskowal> | new Request(url, {body: new Reader(function (write, close, abort) {}) // where write means yield, close means return, and abort means throw |
| 17:01 | <kriskowal> | and probably should be called ByteReader or Uint8Reader |
| 17:01 | <kriskowal> | well, depending on the content type |
| 17:02 | <kriskowal> | and of course an immediately invoked async generator should be isomorphic to a reader |
| 17:03 | <kriskowal> | which i believe should be {next():Promise<{value:T, done:Boolean}>, throw(Error):Promise<Iteration<T>>} |
| 17:05 | <JakeA> | Is Reader an alternative proposal for the ReadableStream constructor or something different? |
| 17:06 | <JakeA> | You can already provide a readable stream as the body option for a response. I think Domenic is looking for something that can be piped to. |
| 17:09 | <kriskowal> | it’s an abstract idea, but serves the same role as ReadableStream |
| 17:10 | <kriskowal> | it’s really a promise iterator |
| 17:10 | <kriskowal> | and a promise buffer is an {in, out} pair of promise generator and promise iterator |
| 17:11 | <kriskowal> | so if you were to var buffer = new Buffer(); and return new Request(url, {body: buffer.out}), you could then write to buffer.in |
| 17:11 | <kriskowal> | or pipe to buffer.in |
| 17:11 | <kriskowal> | and by “pipe” i mean readable.forEach(writable.yield, writable).then(writable.return, writable) |
| 17:12 | <kriskowal> | or just readable.pipeTo(writable, {close: true}) in Domenic’s parlance |
| 17:27 | <zenparsing> | kriskowal reading your general theory - i've been thinking along similar lines, producer/consumer with a promise-based buffer (pipe) as a separate mediating abstraction |
| 17:29 | <kriskowal> | yeah, it will work |
| 17:29 | <kriskowal> | though, just as with promises, there is some overhead to the approach |
| 17:29 | <kriskowal> | and just as with promises, it’s usually acceptable |
| 17:30 | <kriskowal> | but not always. i’m sympathetic to the call to expose a lower level core. |
| 17:32 | <TabAtkins> | See, for example, http://www.xanthir.com/b4PV0 |
| 17:37 | <kriskowal> | TabAtkins: yeah, same germ of an idea |
| 17:38 | <kriskowal> | i would only name things somewhat differently |
| 17:38 | <kriskowal> | but there certainly is a tension between single and plural names |
| 17:38 | <kriskowal> | and whether time series values are singular or plural |
| 17:38 | <TabAtkins> | Right, I'd make different choices on names now too. |
| 17:38 | <kriskowal> | which just comes down to whether plural is spatial or temporal or both |
| 17:38 | <TabAtkins> | Name more of the helper methods FooMap, etc. |
| 17:39 | <kriskowal> | yeah, map is the plural of then |
| 17:39 | <TabAtkins> | Well, flatMap is. |
| 17:39 | <kriskowal> | i might agree :P |
| 17:40 | <kriskowal> | i would only use the term “stream” in situations with pressure and lossless ordered values |
| 17:40 | <kriskowal> | i’m favoring signal and behavior for pull and pull lossy time series data |
| 17:41 | <kriskowal> | but, my thoughts are very fluid atm |
| 17:41 | <kriskowal> | and the pun wasn’t intended, but i don’t mind enjoying it anyway |
| 17:44 | <zenparsing> | kriskowal i might think that a buffer would be able to move data to more than one consumer. no? |
| 17:44 | <kriskowal> | zenparsing: depends on what you mean |
| 17:45 | <kriskowal> | if you were to share the output with multiple consumers, they would round-robin |
| 17:46 | <kriskowal> | but if you mean that they would all see the entire output, you would need to explicitly fork the stream, and all the consumers would be providing pressure |
| 17:46 | <zenparsing> | yes - the second meaning |
| 17:46 | <kriskowal> | a round-robin would effectively relieve pressure on the buffer, but a fork would probably increase the pressure |
| 17:46 | <kriskowal> | at least, the pressure would be the maximum of the forks |
| 17:46 | <zenparsing> | yes exactly |
| 17:47 | <kriskowal> | i have a note to sketch reader.fork() |
| 17:47 | <zenparsing> | that might make sense if you wanted to fork binary input from a file and write tar and zip to separate files, or something like that |
| 17:48 | <zenparsing> | the max pressure would fit in that case |
| 17:53 | <zenparsing> | you could probably write it much more elegantly, but this is where i headed: https://github.com/zenparsing/streamware/blob/master/src/Pipe.js#L131 |
| 18:05 | <kriskowal> | zenparsing: just a sketch, and only covers object transport https://gist.github.com/kriskowal/5bf27a3c734951d2b838 |
| 18:07 | <kriskowal> | working with byte buffers is necessarily more messy |
| 18:08 | <kriskowal> | i took a stab at writing a byte buffer with the same interface, but i’ll have to go at it again later. |
| 18:09 | <kriskowal> | i think that byte buffers just necessitate some different hidden internals that take the fast path, but use the promise buffer machinery for anything that is not a byte buffer to byte buffer interaction |
| 18:11 | <zenparsing> | thanks for the gist - i need to finish reading your article before commenting intelligent-like : ) |
| 18:13 | <zenparsing> | the thing about byte buffers, is that (i think) you want to reuse the underlying memory as much as possible |
| 18:16 | <kriskowal> | yes, so you have a circular queue backed by a uint8array. yield blocks until there’s room to write your chunk, next blocks until there’s enough content to generate a chunk (which is somewhat arbitrary but length>0, length>min || closed) |
| 18:19 | <zenparsing> | yep - and you might also want the circular queue length (total mem allocated to the pipe) to grow or shrink within bounds |
| 18:32 | <TabAtkins> | Byte buffers dont' want to use the same interface as object streams. |
| 18:43 | <wanderview> | JakeA: ping |
| 18:45 | <wanderview> | JakeA: is the CacheStorage caches attribute per-origin or per-domain? all I currently see in the spec is "Caches are not shared across domains", although none of the algorithms for cache explicitly mention an origin/domain check |
| 18:46 | <JakeA> | wanderview: good point. Origin, like IDB |
| 18:47 | <wanderview> | JakeA: cool, I'll write an issue to clarify that in the spec |
| 18:49 | <wanderview> | https://github.com/slightlyoff/ServiceWorker/issues/415 |
| 18:49 | <wanderview> | thanks |
| 18:50 | <JakeA> | wanderview: cheers! |
| 18:51 | <kriskowal> | i think i have caught up with JakeA’s idea of allowing body to be a function |
| 18:51 | <kriskowal> | the way i got here… |
| 18:52 | <kriskowal> | i sketched a promise buffer as an {in, out} promise generator and iterator pair |
| 18:52 | <JakeA> | kriskowal: 1% battery so sorry if late reply |
| 18:52 | <kriskowal> | np, working on the narrative… |
| 18:53 | <kriskowal> | a deferred is conceptually an {in, out} {resolver, promise} pair |
| 18:53 | <kriskowal> | but in that case, we have decided to be very output centric. we expose Promise only, and the constructor reveals the input side |
| 18:55 | <kriskowal> | if streams are a plural analog of Promise, then we would probably expose new Stream(function (_yield, _return, _throw) {}) in the same way we expose new Promise(function (_return, _throw) {}) |
| 18:55 | <kriskowal> | and we could expose Stream.buffer() -> {in, out} in the same way we could expose Promise.defer() -> {in, out} or {resolver, promise} |
| 18:56 | <kriskowal> | which would lead us toward new Request/Response(… {body: new Stream(function (_yield, _return, _throw) {})}) |
| 18:56 | <kriskowal> | but that would introduce a layer of buffering that Domenic and his constituents would like to avoid |
| 18:57 | <kriskowal> | and that layer of buffering could be eliminated by unwrapping the revealing constructor like new Request(url, {body: function (_yield, _return, _throw) {}}) |
| 18:57 | <kriskowal> | which is actually quite elegant |
| 18:58 | <kriskowal> | JakeA: end of line |
| 19:05 | <Hixie_> | jorendorff: why are instantiate and translate diffrent hooks? |
| 19:06 | <jorendorff> | translate is a totally different thing |
| 19:06 | <jorendorff> | translate converts code from some other language to JS |
| 19:17 | <Hixie_> | jorendorff: sure but why couldn't that happen in instantiate? Just have instantiate return either a string or an object, instead of undefined or an object. |
| 19:19 | <jorendorff> | Hixie_: oh - well the reason there are different hooks to begin with, is that the theory is people will want to hack the loader |
| 19:20 | <Hixie_> | sure, but why those two hooks? Why not three? or one? |
| 19:20 | <Hixie_> | i don't understand the value of separating thoe |
| 19:20 | <Hixie_> | the browser doesn't do any work between them, does it? |
| 19:20 | <jorendorff> | i don't know. samth and wycats know more about them |
| 19:20 | <Hixie_> | it just passes the results of one into the other one |
| 19:21 | <jorendorff> | Hixie_: the loader doesn't do any work between those two... i don't think |
| 19:21 | <wycats> | in theory we could have had one giant async hook |
| 19:21 | <jorendorff> | right, and i would have liked that |
| 19:21 | <jorendorff> | but |
| 19:21 | <wycats> | the idea is to break up the process into a number of steps that it makes sense to override |
| 19:21 | <wycats> | so if someone wants to write a translation plugin, they don't need to opt into a separate plugin architecture (like require.js) to do that |
| 19:22 | <jorendorff> | yeah |
| 19:22 | <Hixie_> | wycats: when would you have one bit of code overriding translate and another independent bit of code overriding instantiate? |
| 19:23 | <wycats> | translate might be used for security |
| 19:23 | <wycats> | or for example to compile CS to JS |
| 19:23 | <wycats> | but once CoffeeScript is compiled to JS, the normal instantiate rules apply |
| 19:23 | <wycats> | and you may want your compiled CoffeeScript to use an instantiate hook separately defined for AMD compat |
| 19:23 | <wycats> | (AMD written in CoffeeScript) |
| 19:25 | <wycats> | I honestly don't have a ton of time right this second (or most seconds) :/ |
| 19:25 | <wycats> | realtime chat is great if you can swing it |
| 19:25 | <wycats> | I have a job and whatnot |
| 19:26 | <wycats> | I can try to schedule time to hop in and chat -- gonna be hard to do on an ad hoc basis when tagged in |
| 19:30 | <jorendorff> | Hixie_: I think virtually every conceivable use case for translate will not also want to overload instantiate |
| 19:30 | <jorendorff> | they're pretty independent |
| 19:30 | <jorendorff> | about as independent as you can get |
| 19:46 | <Hixie_> | jorendorff: fair enough. It's hard for me to tell since the spec doesn't give any examples or anything explaining why you'd want to use the features. |
| 19:47 | <jorendorff> | yeah, allen's view is that if you give any kind of rationale or even description of what something does, someone will interpret that as normative and do something stupid with it |
| 19:47 | <jorendorff> | therefore, paint over the signposts |
| 19:48 | <jorendorff> | i'm told HTML has in fact seen that vexing phenomenon, though (thankfully) you've not chosen the same response |
| 19:49 | <Ms2ger> | Someone will, certainly |
| 19:49 | <Ms2ger> | More people will benefit, though |
| 19:49 | <Hixie_> | in the HTML spec we just try to paint "NOT NORMATIVE" signs eveywhere |
| 19:49 | <Ms2ger> | And sometimes it catches bugs where the normative text doesn't specify what it means to |
| 19:49 | <Hixie_> | at this point we have bigger problems from the fact that the w3c is forking the spec than from the non-normative content |
| 19:50 | <jorendorff> | Hixie_: if this Loader stuff ever actually takes off, the translate hook is where you go to monkeypatch new *language features* into older browsers |
| 19:51 | <Hixie_> | jorendorff: and instantiate? |
| 19:51 | <jorendorff> | dherman had a gist illustrating this, but i forget where it was :( |
| 19:52 | <jorendorff> | Hixie_: well :( instantiate is an upgrade path --- it lets you load non-ES6 modules and use them with an 'import' decl, just like ES6 modules. |
| 19:52 | <jorendorff> | Hixie_: so you can have a hybrid app, you don't have to make a Big Leap to es6 modules |
| 19:52 | <Hixie_> | kinda like translating from old-ES to new-ES? :-) |
| 19:52 | <Hixie_> | so i think my biggest problem with reusing the ES6 module loader thing to define the Web's dependency system is that there's no good way for me to declare dependencies before the 'fetch' hook. I really need a way to predeclare the dependencies somehow. |
| 19:53 | <jorendorff> | Hixie_: touche |
| 19:53 | <Hixie_> | (even for ES6 modules) |
| 19:54 | <Hixie_> | like, say you want to import a style sheet. In 'locate' I figure out you mean the <link>, in 'fetch' I tell the <link> "ok, time to go fetch your stuff" and I chain their promise onto the "fetch" result |
| 19:54 | <Hixie_> | translate's a no-op |
| 19:54 | <Hixie_> | and in instantiate I can finally say "oh by the way, this style sheet depends on that one over there" |
| 19:54 | <Hixie_> | by which time it's too late |
| 19:54 | <Hixie_> | I really want "locate" or "fetch" to be able to add dependencies |
| 19:57 | Hixie_ | wonders what "execute" is supposd to do |
| 20:00 | <zenparsing> | as in instantiateResult.execute? |
| 21:10 | <Hixie_> | zenparsing: yeah |
| 21:32 | <Hixie_> | jorendorff: do you know what instantiateResult.execute is supposed to do? |
| 21:34 | <kriskowal> | Hixie_: can you point me at what you’re looking at for reference? |
| 21:35 | <Hixie_> | http://people.mozilla.org/~jorendorff/es6-draft.html |
| 21:35 | <kriskowal> | thanks |
| 21:35 | <Hixie_> | (and http://www.gliffy.com/go/publish/6040024 is my conversion of that to a flowchart) |
| 21:39 | <kriskowal> | this is my implementation of something similar for commonjs in the browser https://github.com/montagejs/mr/blob/v2/common.js#L93-L208 |
| 21:39 | <kriskowal> | but you want definitive answers, not educated guesses, so i’ll lurk |
| 21:39 | <Hixie_> | something similar to what? |
| 21:39 | <kriskowal> | a loader |
| 21:40 | <Hixie_> | i'm happy with educated guesses :-) |
| 21:40 | <Hixie_> | i'm not sure how to interpret that code in the context of the question about instantiateResult.execute though |
| 21:40 | <kriskowal> | right |
| 21:40 | <kriskowal> | i believe that execute is equivalent to calling the module factory function |
| 21:41 | <kriskowal> | so all dependencies have been linked, and it’s just a matter of stepping through the module |
| 21:41 | <Hixie_> | so say the module is an <img>. What should the execute callback do? nothing? |
| 21:41 | <kriskowal> | right, nothing |
| 21:42 | <Hixie_> | how about a style sheet. Should execute be the thing that adds it to the list of active sheets? |
| 21:42 | <kriskowal> | eh, perhaps set the default exports to whatever is appropriate |
| 21:42 | <kriskowal> | style sheets are an interesting case because they have their own internal notions of dependency |
| 21:42 | <kriskowal> | but if style sheets were integrated, i would expect @import() to be resolved by the loader |
| 21:43 | <Hixie_> | well that is exactly what i'm trying to spec right now |
| 21:43 | <kriskowal> | and i would expect that the order of execution would be important for priority |
| 21:44 | <kriskowal> | i would expect that a loaded but not executed style sheet would have no effect. not sure whether that’s possible in the context of ES6 modules though. |
| 21:46 | <Hixie_> | jorendorff: while i'm at it, in "15.2.4.1 LoadModule(loader, name, options) Abstract Operation", step 9 refers to "source", but that doesn't seem to have ever been declared? what is it set to? |
| 22:17 | <Hixie_> | jorendorff: also, what is "name" in 15.2.5.2.2 AddLoadToLinkSet(linkSet, load) Abstract Operation 3.c.i.1 ? |
| 22:31 | Hixie_ | files 8 spec bugs for Modules |
| 22:31 | <MikeSmith> | about "if you give any kind of rationale or even description of what something does, someone will interpret that as normative and do something stupid with it" I think there's a lot to be said for choosing to adopt that and being consistent about not deviating from it |
| 22:32 | <Hixie_> | yeah except there's still some notes and stuff in the ES spec |
| 22:32 | <Hixie_> | just search for "NOTE" |
| 22:32 | <MikeSmith> | ah ok |
| 22:32 | <Hixie_> | (plus it makes the spec unreadable) |
| 22:33 | <MikeSmith> | a lot of things seem to make the ES spec unreadable for most people |
| 22:33 | <MikeSmith> | it's pretty clearly not meant to be read by most people |
| 22:33 | <MikeSmith> | Hixie_: but that said, you're not most people |
| 22:33 | <MikeSmith> | and if it's unreadable for you, that's a problem |
| 22:34 | <Hixie_> | MikeSmith: http://www.gliffy.com/go/publish/6040024 |
| 22:34 | <MikeSmith> | Hixie_: I think even with the WHATWG HTML we have plenty of examples of people mis-interpreting non-normative parts as normative -- and mis-interpreting the document-conformance requirements as UA conformance requirements |
| 22:34 | <Hixie_> | jorendorff: so, is "deps" (returned from the "instantiate" hook") intentionally supposed to be not checked as being a string? is that how i'm supposed to send metadata from "instantiate" to "normalize"? |
| 22:34 | MikeSmith | looks |
| 22:35 | <Hixie_> | MikeSmith: oh yeah no kidding |
| 22:35 | <MikeSmith> | Hixie_: ah yeah I had seen that diagram |
| 22:35 | <MikeSmith> | Hixie_: please don't show that diagram to other people :) |
| 22:35 | <Hixie_> | hah |
| 22:35 | <MikeSmith> | it's too scary |
| 22:35 | <Hixie_> | it has massively helped in my understanding of the spec |
| 22:35 | <MikeSmith> | glad for that at least |
| 22:36 | <Hixie_> | specifically, being able to follow the promise chain (which isn't explicitly in the spec anywhere) |
| 22:36 | <MikeSmith> | a h yeah |
| 22:36 | <Hixie_> | (and which traverses the spec in a completely different order than the spec's explicit internal calls) |
| 22:36 | <MikeSmith> | I have been following some of your comments and questions here on IRC about the promise-chain stuff |
| 22:36 | <Hixie_> | looks like Reflect.Loader.prototype.define() doesn't let you use a non-string name... |
| 22:37 | <MikeSmith> | Hixie_: my main feeling from reading your questions and the responses here is, glad it's you and not me :) |
| 22:37 | <Hixie_> | heh |
| 22:38 | <boogyman> | haha |
| 22:39 | <MikeSmith> | anyway, I think given that we're working in an interactive medium, we could take more advantage of the interactivity as far is presenting the non-normative parts to readers -- through more use of pop-ups, etc. |
| 22:40 | <MikeSmith> | e.g., make the non-normative stuff into annotations |
| 22:40 | <boogyman> | MikeSmith: just hope that anyone of value that needs that img isn't color blind |
| 22:41 | <MikeSmith> | the annotations approach is what I tried to do with http://es5.github.io (which was inspired by a hyperlinked version of the spec that jorendorff had made) |
| 22:41 | <Domenic> | MikeSmith: I think that would require a version of the spec that wasn't in Word ;) |
| 22:41 | <MikeSmith> | heh |
| 22:42 | <MikeSmith> | well Hixie_ should be glad at least that it now has internal hyperlinks |
| 22:42 | <Domenic> | MikeSmith: I didn't know you were the one behind es5.github.io!! I've been using that for years; it is brilliant. |
| 22:43 | <MikeSmith> | before jorendorff got involved in production of it I think none of the uses of the defined terms in the spec where hyperlinked back to the defintions |
| 22:44 | <MikeSmith> | Hixie_: btw I think the dfn pop-ups in the HTML spec could be inspiration for adding some more stuff like that -- and the implementation-status annotations |
| 22:45 | <Hixie_> | once i've actually done some real work (e.g. this loader/dependency thing) I plan to go back and do more on the HTML spec pipeline |
| 22:45 | <MikeSmith> | I think if we had a way for readers/users of the spec to submit annotations that would get added to a set of annotations for the spec after review, that would be great |
| 22:45 | <MikeSmith> | Hixie_: yeah, I figured |
| 22:45 | <Hixie_> | but i wasted enough time just getting more or less to parity :-) |
| 22:45 | <MikeSmith> | heh |
| 22:47 | <MikeSmith> | another thing that it seems has always worked really well is the way the PHP docs incorporate user comments and examples (and the many other projects that since adopted similar things for their docs) |
| 22:48 | <MikeSmith> | 90% of the utility to users of those kinds of docs is in those user-contributed comments and examples |
| 22:49 | <MikeSmith> | of course a spec is something quite a bit different, but stil |
| 22:50 | <Hixie_> | the spec annotations get a lot of spam as it is |
| 22:50 | <Hixie_> | and that's with them being basicaly invisible to most users |
| 22:50 | <Hixie_> | similarly, we had to clamp down on the wiki signups because of spam |
| 22:55 | <MikeSmith> | Hixie_: sure, that's the cost of enabling those kinds of things |
| 22:55 | <Hixie_> | pretty high cost |
| 22:55 | <Hixie_> | speaking of which |
| 22:55 | <Hixie_> | wanna be on the hook to give people wiki accounts? :-) |
| 22:55 | <MikeSmith> | Hixie_: well these days I think a better way to collect user contributions would be using a mechanism based on gihub forks and PRs |
| 22:56 | <MikeSmith> | Hixie_: see what html5please does |
| 22:56 | <MikeSmith> | Hixie_: I am already on the hook! |
| 22:56 | <Hixie_> | you get teh admin@ e-mail? |
| 22:56 | <MikeSmith> | Hixie_: I've done a bunch of wiki user-account creations already |
| 22:56 | <Hixie_> | oh, cool |
| 22:57 | <MikeSmith> | Hixie_: no, but would be glad to be on admin@ mail to help with whatever else is needed there |
| 22:57 | <Hixie_> | also, http://html5please.us/ o_O |
| 22:57 | <Hixie_> | oh, cool |
| 22:57 | <Hixie_> | let me add you! :-D |
| 22:58 | <MikeSmith> | cool |
| 23:01 | <boogyman> | lol. of course that site is related to Insurance Rates |
| 23:03 | <Hixie_> | MikeSmith: mike⊙wo ? |
| 23:03 | <MikeSmith> | Hixie_: yeah please |
| 23:08 | <roc> | Just try this link. If it doesn't work right away, I'll switch to Vidyo |
| 23:08 | <roc> | oops |