| 09:53 | <annevk> | morning |
| 10:36 | <annevk> | *shakes fist at pointer events specification* |
| 13:18 | <annevk> | MikeSmith: partially addressed your domain bug |
| 13:18 | <annevk> | Updated the URL Standard to resolve IDNA issues. |
| 13:18 | <annevk> | mathiasbynens: jtcranmer: I made the domain statics return the empty string in case the result was failure or an IPv6 address |
| 13:19 | MikeSmith | looks |
| 13:19 | <annevk> | MikeSmith: http://url.spec.whatwg.org/#valid-domain |
| 13:19 | <MikeSmith> | ah "valid domain" cool |
| 13:19 | <mathiasbynens> | annevk: thanks for the heads up |
| 13:20 | <MikeSmith> | hah "Ideally we define this in terms of a sequence of code points that make up a valid domain rather than through a whack-a-mole" 🐙 |
| 13:23 | <MikeSmith> | me wonders out of curiosity under what cases Unicode ToASCII fails |
| 13:23 | <MikeSmith> | and Unicode ToUnicode |
| 13:24 | <MikeSmith> | just DNS length restrictions? |
| 13:25 | <MikeSmith> | ah nah, more |
| 13:25 | <MikeSmith> | can "Convert each label with non-ASCII characters into Punycode" fail? |
| 13:30 | <annevk> | MikeSmith: I think Punycode does not fail |
| 13:32 | <MikeSmith> | ok |
| 13:33 | <annevk> | MikeSmith: I might be wrong, http://tools.ietf.org/html/rfc3492 lists a number of "fail" conditions in the pseudo-algorithms, but they are hard to decipher |
| 13:33 | MikeSmith | looks |
| 13:34 | <MikeSmith> | "fail on overflow" |
| 13:36 | <annevk> | mathiasbynens might know |
| 13:36 | <MikeSmith> | annevk: btw the validator just uses galimitas which for toASCII just uses http://docs.oracle.com/javase/6/docs/api/java/net/IDN.html which claims to conform to RFC 3490 |
| 13:37 | <annevk> | MikeSmith: that sounds pretty bogus |
| 13:37 | <annevk> | MikeSmith: the whole idea that IDNA is Punycode is misguided |
| 13:37 | <MikeSmith> | annevk: and galimatis reports "Could not convert domain to ASCII" if it fails, and the validator just catches that and emits it |
| 13:41 | <annevk> | MikeSmith: oh wait, 3490, that's somewhat correct, except it is IDNA2003 and not UTS #46 |
| 13:41 | <MikeSmith> | annevk: yeah |
| 13:42 | <MikeSmith> | annevk: but UTS #46 just references RFC3490 for toASCII, right? |
| 13:42 | <annevk> | MikeSmith: no |
| 13:42 | <MikeSmith> | oh |
| 13:43 | <annevk> | MikeSmith: http://www.unicode.org/reports/tr46/proposed.html#ToASCII it defines an operation like RFC 3490, but with a twist |
| 13:43 | <MikeSmith> | ah "The operation corresponding to ToASCII of [RFC3490] is defined by the following steps" |
| 13:44 | <MikeSmith> | annevk: yeah I see now |
| 13:44 | <MikeSmith> | I had misread it the first time |
| 13:44 | <annevk> | I wish they would just remove the 3490 bit |
| 13:44 | <MikeSmith> | annevk: bingo |
| 13:44 | <MikeSmith> | I was about to say the same thing |
| 13:44 | <annevk> | This whole concept of acknowledging history at the same place you define fundamental algorithms is totally misguided |
| 13:44 | <MikeSmith> | yup |
| 13:45 | <MikeSmith> | and mention of 3490 should be in a note following the algorithm -- if there's any mention at all |
| 13:46 | <MikeSmith> | and even then it should do what the HTML spec does, and clearly state, "This is a wilful violation of RFC 3490" |
| 13:46 | <MikeSmith> | or that it "replaces" the corresponding part of 3490, or whatever |
| 13:51 | <MikeSmith> | smola: ↑ |
| 13:51 | <MikeSmith> | I guess there's no Java library that implements UTS #46 |
| 13:52 | <annevk> | At some point we should write some guidance on writing specifications |
| 13:54 | <MikeSmith> | annevk: yeah that would be good |
| 13:54 | <MikeSmith> | though I reckon many spec writers would still ignore it |
| 13:55 | <MikeSmith> | annevk: btw I think the reason some devs use XPath instead of querySelector is just inertia |
| 13:56 | <annevk> | MikeSmith: I was thinking they might, especially those that already write specifications |
| 13:56 | <annevk> | MikeSmith: reading dev.platform? :-) |
| 13:57 | <MikeSmith> | annevk: about specs yeah I guess some part of the badness is just ignorance about how to write specs more precisely |
| 13:58 | <MikeSmith> | annevk: the RDFa editors sure would have benefitted from some guidance |
| 13:58 | <Ms2ger> | Ha |
| 13:58 | <annevk> | Seems like CSS might too. RFC 2119 usage is often incorrect. Concepts such as "sibling" are used without definition... |
| 13:59 | <jgraham> | On the other hand their usage of RFC 6919 is examplary |
| 13:59 | <MikeSmith> | annevk: yeah, I think those devs could just replace their XPath expressions with selectors equivalents with very little effort |
| 14:00 | <annevk> | jgraham: seems like you found an RFC that allows the W3C to take HTML to REC |
| 14:01 | <jgraham> | But it is true that CSS can't yet do all the things that xpath can |
| 14:01 | <jgraham> | XPath can do crazy things like "find an a containing the text 'foo' and give me the href attribute of its siblings' third ancestor" |
| 14:02 | <MikeSmith> | jgraham: yeah but I doubt most of them are using xpath expressions that don't have selectors equivalents |
| 14:02 | <jgraham> | I bet a lot of the Selenium users are |
| 14:02 | <MikeSmith> | jgraham: right. the thing is if they're doing that the performance is probably pretty bad anyway |
| 14:02 | <jgraham> | I wouldn't be surprised if some of the extension users were too |
| 14:02 | <jgraham> | What, using Selenium? |
| 14:03 | <MikeSmith> | jgraham: well this is in the context of web applications |
| 14:03 | <MikeSmith> | and browser extensions |
| 14:03 | <jgraham> | For browser extensions being able to do things like conveniently get the text out of attributes is nice to have |
| 14:03 | <MikeSmith> | jgraham: I mean those extensions would probably be causing a performance hit |
| 14:04 | <MikeSmith> | yeah I can see that |
| 14:04 | <jgraham> | MikeSmith: It's not clear to me why they would cause a noticable perf. hit |
| 14:04 | <jgraham> | Is our XPath support notably slow? |
| 14:05 | <Ms2ger> | Faster than the polyfill in IE, apparently |
| 14:06 | <annevk> | To get back to the pointer events thing... "If you can propose spec text that might make this clearer, I'm happy to take a look." is such a shitty response. Editors not taking responsibility for problems are the worst |
| 14:06 | <gsnedders> | even nowadays? how good is the polyfill? |
| 14:07 | <annevk> | If you get enough of that you can basically declare "Specification Lost" |
| 14:07 | <annevk> | Context: http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0012.html |
| 14:08 | <gsnedders> | jgraham: But your XPath support is far slower than CSS selectors. |
| 14:11 | <jgraham> | gsnedders: Well, for the things that CSS can't do, the relevant comparison is CSS + custom js code |
| 14:13 | <gsnedders> | jgraham: Right, but in the case of them being equiv CSS selectors win. I'm pretty sure most of the polyfills could be more efficient. And String.prototype.indexOf uses naive search in everything but Chakra (le sigh). |
| 14:14 | <jtcranmer> | as opposed to a KMP search? |
| 14:15 | <gsnedders> | jtcranmer: or similar, yes |
| 14:15 | <jtcranmer> | for most use cases of String.indexOf, I'd expect KMP-like searches to have much higher overhead |
| 14:17 | <gsnedders> | jtcranmer: Yeah, certainly especially when searching small strings it's likely not worthwhile |
| 14:17 | <gsnedders> | jtcranmer: I've seen cases where the cost of the naive string search algorithm was a notable bottleneck, though |
| 14:20 | <jtcranmer> | I don't doubt that |
| 14:21 | <jgraham> | Sure, like everything in js you want to dynamically switch to more efficient algorithms when you detect it is likely to be worthwhile |
| 14:26 | <gsnedders> | jgraham: Nobody does that (except for some never-merged (AFAIK) branch of Carakan) for indexOf though. |
| 14:27 | <gsnedders> | And with some text nodes that's likely to make a difference with contains in XPath |
| 14:48 | <Ms2ger> | gsnedders, I thought spidermonkey did something of the kind |
| 14:50 | <gsnedders> | Ms2ger: tbf, this was a few years back I was looking, but I didn't see any such behaviour? |
| 14:50 | <gsnedders> | Ms2ger: I could've missed something, though |
| 14:56 | <SamB> | sibling's third ancestor? sounds a bit redundant ... |
| 14:58 | <jgraham> | OK, fair enough :p |
| 14:58 | <jgraham> | But the point was that you can do more complex things in XPath than CSS Selectors |
| 14:59 | SamB | can't help but wonder if an implementation would notice and optimize that out |
| 14:59 | <SamB> | hmm, actually, I guess it might do something: what if the sibling in question wasn't there ... |
| 15:02 | <gsnedders> | Well, I mean //a::text()[contains(., 'foo')]/following-sibling::*[position()==1]/ancestor::*[position()==3]/@href is what jgraham was talking about |
| 15:02 | <gsnedders> | SamB: Yeah, indeed, thus why that's important |
| 15:03 | <gsnedders> | (There are other equivalent queries, it must be said) |
| 15:04 | <gsnedders> | //a::text()[contains(., 'foo') && following-sibling::*]/ancestor::*[position()==3]/@href for example moves the selection of following sibling |
| 15:57 | <Domenic_> | JakeA: this is kind of cool https://www.npmjs.org/package/es6-promisify |
| 16:03 | <JakeA> | Domenic_: Ohh, that's cool. Although rsvp will do it out of the box |
| 17:10 | <TabAtkins> | annevk: Uh, you know that I meant that "if you can propose something" sincerely, right? I"m not just brushing you off? Because I'm not a huge dick? |
| 17:10 | <TabAtkins> | Oh, sorry, missed context. That was Pointer Events. |
| 17:11 | <TabAtkins> | I said something similar to you yesterday, so I wasn't sure. |
| 17:11 | <SamB> | ;-) |
| 17:21 | <annevk> | TabAtkins: you are huge though |
| 17:21 | <TabAtkins> | True, but I'm not literally a dick. |
| 17:21 | <TabAtkins> | And ::blushes:: don't share secrets, dude. |
| 17:21 | <TabAtkins> | I thought that was special between us. |
| 17:22 | <annevk> | TabAtkins: dude, I was referring to your height, not that … |
| 17:22 | <TabAtkins> | Mm hm. |
| 17:22 | <annevk> | tut tut |
| 17:43 | <SamB> | Hixie: see http://www.slideshare.net/fullscreen/dakami/black-ops-2012/39 through at least 42 re: what's the point of using JSON ... |
| 18:22 | SamB | wonders if there's some way to prevent <img> from attempting HTTP authentication ... goes to read spec ... |
| 18:25 | SamB | mutters something about the seemingly random page splitting in the HTML spec ... |
| 18:37 | <TabAtkins> | Hixie: Would you be willing to push harder on the WHATCG thing? plinss is refusing to point Bikeshed's link refs to the WHATWG HTML spec, because we won't be allowed to publish RECs with it. |
| 18:38 | <SamB> | what's WHATCG supposed to be? |
| 18:38 | <TabAtkins> | SamB: The page splitting is done by hand, and was done a long time ago. At that point the splits were roughly even, but the spec has changed a lot since then. |
| 18:38 | <SamB> | TabAtkins: it's nothing to do with "evenness" |
| 18:38 | <TabAtkins> | A Community Group whose sole purpose is to publish heartbeats fo the WHATWG HTML spec regularly, and get the browsers to sign off on them for patent policy purposes. |
| 18:39 | <SamB> | just looks kind of silly going to #the-img-element and seeing a title of "4.6 Edits" |
| 18:39 | <SamB> | TabAtkins: ah, so the W3C has an actual *reason* for not wanting to link to WHATWG specs? |
| 18:40 | <TabAtkins> | Patent Policy, as always, is the bugaboo. |
| 18:40 | <SamB> | one more practical than "but you keep changing it", even |
| 18:40 | <TabAtkins> | Yeah, that one's just people being jackasses. |
| 18:41 | <SamB> | since we all know how well that works with e.g. Unicode references ... |
| 18:42 | <SamB> | now "but you keep breaking our links" would be a real reason, of course |
| 19:18 | <aklein> | who knows things about interactions between ES6 collections and WindowProxy? I'd expect bz, but I don't see him around. |
| 19:29 | <Domenic_> | TabAtkins: but it's the EDs that matter; RECs are just for lawyers. Can't that be a pre-REC last-minute-change? |
| 19:29 | <TabAtkins> | Hm, I'd have to do some Bikeshed hacking, but maybe. |
| 19:30 | <Domenic_> | (IMO adding a big old "just for lawyers" disclaimer to anything in TR/ seems like a worthwhile thing to do.) |
| 19:30 | <Domenic_> | TabAtkins: awesome that you're pushing on this. |
| 19:40 | <bz_moz> | aklein: You were looking for me? |
| 19:45 | <Domenic_> | woah it's bz on IRC! :O |
| 19:47 | bz_moz | was summoned |
| 19:47 | <bz_moz> | Also, I'm always on IRC. |
| 19:47 | <bz_moz> | Just not on this network. ;) |
| 20:00 | <aklein> | bz_moz: back from lunch, still around? |
| 20:01 | <aklein> | bz_moz: I'm curious what should happen if one uses passes a Window as the key to an ES6 Map/Set (or WeakMap/WeakSet) |
| 20:02 | <bz_moz> | Hmm |
| 20:02 | <sgalineau> | is the 'no links to WHATWG specs' even followed consistently? |
| 20:02 | <sgalineau> | wild guess: probably not |
| 20:02 | <bz_moz> | aklein: Excellent question |
| 20:03 | <bz_moz> | aklein: I _think_ Gecko+SpiderMonkey uses the windowproxy as-is as the key |
| 20:04 | <bz_moz> | aklein: and in particular, that you can use it as a key across navigations |
| 20:04 | <aklein> | bz_moz: that's what it looks like from a quick test |
| 20:04 | <sicking> | Domenic_: why couldn't a buffering strategy be passed to the ctor? |
| 20:04 | <bz_moz> | aklein: But that's based on code inspection, not experiment |
| 20:04 | <aklein> | bz_moz: the current Blink/V8 implementation does the opposite |
| 20:04 | <Domenic_> | sicking: there is no ctor in the channel proposal |
| 20:05 | <sicking> | Domenic_: aah, "Channel()" vs. "new Channel()"? |
| 20:05 | <bz_moz> | aklein: Exciting |
| 20:05 | <Domenic_> | sicking: yeah. Which brings up the question of how input and output came to be. What are they instances of, etc. |
| 20:05 | <bz_moz> | bholley: Good. You're needed in this conversation. ;) |
| 20:05 | <bz_moz> | bholley: topic: windows as keys for map/set/weakmap |
| 20:05 | <aklein> | bz_moz: I've also heard some argue that it they should throw |
| 20:06 | <bz_moz> | bholley: aklein says that Blink/V8 uses the Window in this case |
| 20:06 | <bz_moz> | bholley: Gecko uses the WindowProxy |
| 20:06 | <bholley> | bz_moz: can't talk right now - send me mail? |
| 20:06 | <aklein> | or, alternatively, that Ecmascript should decide how Proxies work and try to use that behavior |
| 20:06 | <bz_moz> | aklein: an interesting factor here from Gecko's pov is that our security membranes are around the WindowProxy, not the Window |
| 20:06 | <bz_moz> | bholley: ok |
| 20:06 | <sicking> | Domenic_: you'll probably not like the answer :) |
| 20:06 | <Domenic_> | exactly |
| 20:07 | <bz_moz> | aklein: so any time you might have a cross-global reference it ends up going through WindowProxy |
| 20:07 | <sicking> | Domenic_: they can test true for "readable instanceof ReadableStream". But you wouldn't be able to instantiate a ReadableStream directly |
| 20:07 | <sicking> | Domenic_: it's unclear to me what downside that has though |
| 20:07 | <bz_moz> | aklein: and as a side note, a self-hosted set implementation would end up using the WindowProxy always, since you can't get at Window from script. |
| 20:07 | <aklein> | bz_moz: when I say that V8 stores the Window, I just mean that the Window is what's used to generate the hash code/check for equality |
| 20:07 | <Domenic_> | sicking: how did that ReadableStream get created in the first place? |
| 20:08 | <sicking> | Domenic_: i know Alex likes to beat the "everything should have a constructor" drum, but i'm not convinced |
| 20:08 | <bz_moz> | aklein: right, so once you navigate, your key's identity changes |
| 20:08 | <bz_moz> | aklein: effectively |
| 20:08 | <aklein> | bz_moz: right |
| 20:09 | <bz_moz> | aklein: this seems like a siuation where we should go back to use caes... |
| 20:09 | <aklein> | bz_moz: self-hosting point is interesting...do you get the impression that WindowProxy is indeed implementable using ES6 Proxies? |
| 20:09 | <bz_moz> | er, cases |
| 20:09 | <bz_moz> | aklein: Not fully |
| 20:09 | <Domenic_> | sicking: well how did those objects get created in the first place, if not by constructors? |
| 20:09 | <bz_moz> | aklein: The part that is not implementable, imo, is having "this" return the windowproxy at global scope |
| 20:10 | <aklein> | bz_moz: ah, I guess I care less about that for these purposes |
| 20:10 | <bz_moz> | aklein: And perhaps some weirdness in terms of bareword getter invocations on the global and the this object those getters see |
| 20:10 | <bz_moz> | Apart from that I think it is, yes |
| 20:11 | <bz_moz> | windowproxy is not really very magic in terms of what it does. |
| 20:11 | <sicking> | Domenic_: they can be just plain "dictionaries" but with a .prototype set to ReadableStream |
| 20:11 | <bz_moz> | bholley has a proposed spec for it... lemme dig it up |
| 20:11 | <Domenic_> | sicking: how were they created, though? |
| 20:11 | <sicking> | Domenic_: new Object() |
| 20:12 | <aklein> | bz_moz: anyway, V8 folks are inclined to switch to something like the SpiderMonkey semantics, but it smelled kinda funny to me; if expandos disappear with navigation, why not "private" expandos implemented using WeakMap? |
| 20:12 | <Domenic_> | sicking: so how do you access their internal state? |
| 20:12 | <Domenic_> | sicking: wait for my reply in-thread |
| 20:12 | <sicking> | Domenic_: how is this different from the object that's passed to the ReadableStream constructor? |
| 20:13 | <bz_moz> | aklein: So the main reason expandos disappear on navigation is to prevent sites polluting each others global scopes |
| 20:13 | <bz_moz> | aklein: at least that's how it started |
| 20:13 | <bz_moz> | aklein: that would not be an issue in the weakmap case |
| 20:13 | <bz_moz> | aklein: but yes, I agree it could be a bit weird |
| 20:13 | <sicking> | Domenic_: ReadableStream also has a bunch of internal state which can't be accessed from the outside. The only difference here is that both sides could be tested with instanceof |
| 20:14 | <bz_moz> | aklein: I _really_ wish we had distinct objects representing "the navigation context" and "the global currently inside the navigation context" |
| 20:14 | <bz_moz> | aklein: instead of the mess we have right now |
| 20:14 | <Domenic_> | sicking: the revealing constructor pattern *explains* how you can have access to something's internals |
| 20:14 | <bz_moz> | aklein: But I can't have that pony.... |
| 20:14 | <sicking> | Domenic_: i don't see the difference |
| 20:15 | <sicking> | oh, wait, i think i read that wrong |
| 20:15 | <sicking> | Domenic_: nm |
| 20:15 | <Domenic_> | sicking: between `var x = {}; x.__proto__ = ReadableStream.prototype; addABunchOfInternalStateTo(x); manipulateInternalStateOf(x);` and `var x = new ReadableStream(manipulateInternalState)`? |
| 20:16 | <Domenic_> | sicking: there is not much difference besides the former is awkward and tries to dodge JS constructor semantics all the while reinventing them; while the latter uses the language as it is. |
| 20:17 | <sicking> | the resulting ReadableStream interface seems identical, no? |
| 20:18 | <sicking> | Domenic_: i'm not married to how you construct these things |
| 20:18 | <aklein> | bz_moz: sounds like this ought to be a public-script-coord thread? |
| 20:18 | <sicking> | Domenic_: one option is to simply do somehting like this |
| 20:19 | <sicking> | Domenic_: `var x = new ReadableStream((WritableStream) => { ... })` |
| 20:19 | <bz_moz> | aklein: yes |
| 20:20 | <sicking> | Domenic_: if you prefer that over `{ readable, writable } = <new> Channel()` then i'm fine with that too |
| 20:20 | <bz_moz> | aklein: we should figure out use cases |
| 20:20 | <bz_moz> | aklein: like "associate stuff with this window" vs "associate stuff with the stuff currently in this window". :( |
| 20:20 | <bz_moz> | aklein: maybe we need both behaviors in different cases or some such insanity. :( |
| 20:20 | <aklein> | bz_moz: those are indeed the use cases :) |
| 20:21 | <aklein> | bz_moz: the current HTML spec text tends towards the latter: "This object is unusual in that all operations that would be performed on it must be performed on the Window object of the browsing context's active document instead". But I suspect that wasn't considering object identity to be a thing |
| 20:21 | <Domenic_> | sicking: see my longer post https://github.com/whatwg/streams/issues/102#issuecomment-40442921 where I analyze that possibility |
| 20:22 | <Domenic_> | sicking: you can't get away with just that. it needs to be more like `new ReadableStream({ start(ws) { .. }, pull(ws) { ... }, cancel() { ... } })` |
| 20:23 | <Domenic_> | sicking: and at that point the difference between (push, done, error)` and `({ write, close, abort })` is simply that the latter implies a false symmetry whereas the former communicates the underlying semantics more clearly. |
| 20:23 | <sicking> | Domenic_: i guess i care less about how these things are constructed. I'd prefer to optimize for having a simple API. |
| 20:23 | <sicking> | Domenic_: I agree it's a tricky situation since we want to create a pair of objects that have an inherent connection to each other |
| 20:23 | <Domenic_> | sicking: for sure. I think they're not that bad though. I think you're really feeling the lack of a transform stream helper. |
| 20:24 | <sicking> | Domenic_: no, my main concern is too much API surface, not a lack of sugar |
| 20:24 | <aklein> | bz_moz: while I have you around I also wanted to pick your brain about what ES6 should do about the notion of the "entry settings object" in HTML (which is also just now coming up in the Blink/V8 implementation of Promises) |
| 20:25 | <Domenic_> | sicking: OK, fair. But I think we're solving a large problem and doing it without the benefit of magic to hide API surface from us. |
| 20:25 | <aklein> | bz_moz: annevk helpfully pointed me to a recent es-discuss thread on the issue but I didn't see any conclusion |
| 20:25 | <bz_moz> | aklein: There wasn't any |
| 20:25 | <Domenic_> | sicking: if you look at the old W3C streams draft they had no constructors, which achieves the level of simplicity you are aiming at, but of course at the cost of lack of explanatory power. |
| 20:25 | <Domenic_> | sicking: the actual consumer-level API surface is pretty simple. |
| 20:26 | <bz_moz> | aklein: I gave up trying to convince people that this needs solving, for now |
| 20:26 | <bz_moz> | aklein: though of course it does need solving. |
| 20:26 | <aklein> | bz_moz: the highest-level question I had was "how important is this concept for new APIs?" |
| 20:26 | <sicking> | Domenic_: actually, i think it'd work if we just create something like `new ReadableStream((wriablestream) => { ... })` |
| 20:26 | <aklein> | bz_moz: it seems like only a few DOM APIs depend on it |
| 20:27 | <bz_moz> | aklein: it's basically needed for any API that can call from "the platform" into "user script", whatever that means |
| 20:27 | <sicking> | Domenic_: the writablestream could have a constructor which you need to pass some internal communication object |
| 20:27 | <sicking> | Domenic_: then ReadableStream could create that internal communication object |
| 20:27 | <bz_moz> | aklein: WebIDL currently defines that to be any time a WebIDL callback or callback interface is invoked |
| 20:27 | <sicking> | Domenic_: hrm... we'd still be left with that internal communication object being exposed as an API surface but that no-one should use ever |
| 20:28 | <sicking> | Domenic_: no-one other than ReadableStream that is |
| 20:28 | <aklein> | bz_moz: I thought this was defined by HTML...maybe it's moved? I did see Hixie asking heycam|away to change something about this |
| 20:28 | <bz_moz> | aklein: HTML defines the settings object stack, kinda |
| 20:28 | <bz_moz> | aklein: WebIDL defines how it's used |
| 20:28 | <Domenic_> | sicking: plus, that doesn't work, since WritableStream by itself isn't enough to form a new readable stream |
| 20:29 | <bz_moz> | aklein: it's not a great situation. :( |
| 20:29 | <sicking> | Domenic_: how so? |
| 20:29 | <Domenic_> | sicking: as I said, it's more like `new ReadableStream({ start(ws) { .. }, pull(ws) { ... }, cancel() { ... } })` |
| 20:29 | <aklein> | bz_moz: right, and ES refers to neither of those |
| 20:29 | <Domenic_> | sicking: because you need (1) to define what happens on startup; (2) to define what happens in reaction to pull; (3) to define what happens in reaction to cancel |
| 20:29 | <bz_moz> | aklein: yup |
| 20:29 | <Domenic_> | sicking: (1) and (2) perform operations that look something like writing into a writable stream, if you tilt your head funny |
| 20:29 | <sicking> | Domenic_: on startup the stream is empty |
| 20:29 | <Domenic_> | sicking: (but are actually more like pushing into a queue) |
| 20:29 | <Domenic_> | sicking: but how do you e.g. open a file handle? |
| 20:30 | <aklein> | bz_moz: agreed. but even if we can't get it specified properly for organizational reasons it'd be nice to get some compatibility between implementations of, e.g., Promises |
| 20:30 | <aklein> | bz_moz: is the SpiderMonkey/Gecko behavior to treat these new ES things as if they were WebIDL callbacks? |
| 20:30 | <sicking> | Domenic_: that's hard to answer given that ES6 doesn't have a concept of opening a file handle |
| 20:30 | <Domenic_> | sicking: i think you're missing the point... |
| 20:31 | <bz_moz> | aklein: the current Promise impl in Gecko is not in SpiderMonkey; it's in Gecko proper and defined via WebIDL |
| 20:31 | <bz_moz> | aklein: so yes, it follows whatever our webidl implementation's rules are |
| 20:31 | <sicking> | Domenic_: but conceptually you'd open a file handle, then start feeding data from it into the WritableStream |
| 20:31 | <aklein> | bz_moz: amusingly this came up in Blink/V8 land because we're switching from a Blink implementation to one in V8 |
| 20:31 | <sicking> | Domenic_: until the WritableStream indicates back pressure |
| 20:31 | <Domenic_> | sicking: so, that's what start(ws) { ... } would do. It uses the context to expose the internal ws to you |
| 20:31 | <sicking> | Domenic_: then you stop reading until the WritableStream indicates that back pressure is off |
| 20:32 | <Domenic_> | sicking: ok, now you need two more hooks: one to react to pulls, and one to react to cancels. |
| 20:32 | <Domenic_> | sicking: if we didn't have pull() and cancel(), then it could be `new ReadableStream(ws => ...)` |
| 20:32 | <sicking> | Domenic_: WritableStream already has the needed surface, no? |
| 20:32 | <Domenic_> | sicking: nope. how do you close the underlying file descriptor in reaction to a cancellation? |
| 20:33 | <Domenic_> | sicking: and how do you get notified that someone wants to read from your readable stream, if all you have access to is a writable stream? |
| 20:33 | <sicking> | Domenic_: .closed.then(() => { closeFileHandle() }) |
| 20:33 | <Domenic_> | sicking: cancellation is pretty clear-cut. it doesn't involve the writable side at all |
| 20:35 | <Domenic_> | sicking: how do you distinguish between purposeful premature cancellation and natural end-of-file closing? |
| 20:35 | <Domenic_> | sicking: you'd have to add a new public `.cancelled` hook |
| 20:35 | <sicking> | Domenic_: You close in the response to the .closed promise resolving. You get notified about someone wanting to read by using .state and wait() |
| 20:36 | <Domenic_> | sicking: .state and .wait() on the writable stream side have nothing to do with someone wanting to read from the readable stream side |
| 20:36 | <sicking> | Domenic_: the end-of-file isn't something that the reader indicates |
| 20:36 | <sicking> | Domenic_: that seems wrong? |
| 20:36 | <Domenic_> | sicking: right, but if you make me depend on the public .closed interface, i can't distinguish what the reader indicates from what the internals indicate |
| 20:37 | <Domenic_> | sicking: how so wrong? it's clearly true that if i call rs.read(), nothing at all happens to the writable stream. |
| 20:37 | <aklein> | bz_moz: anyway, we're working on the v8 team to see if we can at least get their stuff to better understand the HTML/WebIDL way of doing callbacks |
| 20:37 | <bz_moz> | aklein: sounds good. :) |
| 20:38 | <sicking> | Domenic_: we clearly have very different models in our head |
| 20:38 | <Domenic_> | sicking: mind coding yours up? :) |
| 20:39 | <sicking> | Domenic_: sadly i don't have the time. I'm trying to get Gozala to do it, but he's also set on chaing the ReadableStream and WritableStream interfaces which I think clouds the conversation |
| 20:39 | <Domenic_> | sicking: :-/ |
| 20:39 | <sicking> | i also won't be writing it in a style that looks very JSy as I'm not a JS guy |
| 20:40 | <sicking> | i feel confident that I can create a channel object which has your ReadableStream API on one side, and your WritableStream API on the other side |
| 20:41 | <sicking> | and that that would be all that's needed (modulo maybe minor tweaks that I've missed) |
| 20:42 | <sicking> | the constructor part is tricky I agree |
| 20:42 | <sicking> | I can't see a way to do that without exposing either useless interfaces to the outside world, or by using C++ magic |
| 20:43 | <sicking> | i don't know which is worse |
| 20:45 | <Domenic_> | I don't see what advantages this has over the existing model. |
| 20:46 | <Domenic_> | It is just a no-op transform stream |
| 20:46 | <Domenic_> | those will be easy to create |
| 20:46 | <Domenic_> | and if people want to use them directly and handle all the relevant complexity themselves, more power to them. |
| 20:47 | <Domenic_> | but at least we'll have explained where they come from |
| 20:47 | <Domenic_> | and given a more usable alternative (viz. using the original constructors) |
| 21:06 | <sicking> | the only advantage is that there's a smaller API |
| 21:07 | <sicking> | i'm not sure if the smaller API comes at the cost of reduce performance |
| 21:07 | <sicking> | but that's what i'd like to explore |
| 21:08 | <sicking> | but if there's a performance cost to it, then that makes the current Readable/WritableStream APIs (not impl) somewhat suspect |
| 21:09 | <Domenic_> | I think the smaller API can be achieved by just teaching people `var { input, output } = transformStreamFactory(function (x) { return x; })` and not teaching them the constructors |
| 21:09 | <Domenic_> | I don't think it makes them suspect, because you are twisting them into situations they were not meant for |
| 21:09 | <Domenic_> | you are trying to use them for something that is actually just a simple queue |
| 21:09 | <Domenic_> | and doesn't have all of the complexity of a full stream |
| 21:12 | <sicking> | is perhaps this complexity something that's needed for IO streams, but not for other streams? |
| 21:14 | <Domenic_> | if we take "IO streams" to mean "streams that handle buffering for you while staying performant for sync cases" then yes, I think so. |
| 21:16 | <Domenic_> | there's a large cottage ecosystem in Node.js of making it easy to simply create/consume/etc. "observables," with Node streams underlying them. |
| 21:16 | <Domenic_> | e.g. "mapStream" etc. |
| 21:17 | <Domenic_> | and DSLs so that `myObservable.map(fn)` becomes shorthand for `readableStream.pipe(new MapStream(fn))` |
| 21:17 | <Domenic_> | Yehuda and I have some thoughts on how to integrate these observables well with streams |
| 21:18 | <Domenic_> | e.g. if observables end up being described by a `.subscribe(onNext, onError, onComplete)` in a similar fashion to promises |
| 21:18 | <Domenic_> | then we could add that to readable streams so that they duck-type as observables |
| 21:43 | <bholley> | bz_moz: here now |
| 21:54 | <annevk> | ah you guys, discussing all the interesting stuff while I was at the movies |
| 21:56 | <Domenic_> | was it a good movie at least? |
| 21:58 | <annevk> | bz_moz: this being WindowProxy we should solve by ES providing a hook for the embedder to set this to something else than the global |
| 22:00 | <annevk> | aklein: either Domenic_ or Allen should solve the issue with promises and the settings object |
| 22:00 | <annevk> | Domenic_: yes, a classic, Castle in the Sky |
| 22:01 | <annevk> | I just realized that with https://bugs.ecmascript.org/show_bug.cgi?id=1898 not fixed, the Realm API is probably not adequate in expressing the current setup |
| 22:01 | <Domenic_> | ah yes, always fun |
| 22:01 | <Domenic_> | annevk: that seems urgent |
| 22:02 | <annevk> | Domenic_: I guess I'll email es-discuss again, see what they say... |
| 22:02 | <Domenic_> | annevk: the realm api argument helps |
| 22:03 | <Domenic_> | annevk: I still think my position on script settings objects from http://esdiscuss.org/topic/specification-styles#content-15 is the most tenable |
| 22:05 | <annevk> | Domenic_: why? That doesn't seem to match existing implementations |
| 22:06 | <annevk> | Domenic_: note that Chrome / V8 ran into the problem bz_moz described |
| 22:06 | <Domenic_> | annevk: what part of my message are you saying doesn't match existing implementations? |
| 22:06 | <annevk> | Domenic_: this is why promises are not shipping in Chrome 35 |
| 22:07 | <Domenic_> | yes, i remember |
| 22:08 | <Domenic_> | annevk: there are certain WebIDL functions/getters/setters that have exotic [[Call]] that depends on global state |
| 22:08 | <Domenic_> | annevk: this should be specified in their definition of [[Call]], not in ES's |
| 22:10 | <annevk> | Domenic_: no, this is valid for all new entry points |
| 22:10 | <annevk> | Domenic_: until you had an event loop, you did not have this problem, because you could not create new entry points |
| 22:12 | <annevk> | Domenic_: in particular, "async" callbacks need to use http://www.whatwg.org/specs/web-apps/current-work/#jump-to-a-code-entry-point (this problem sort of exists in IDL too, it's not well defined yet) |
| 22:13 | <Domenic_> | annevk: but that's only relevant to certain WebIDL funcitons that depend on the script settings object |
| 22:13 | <Domenic_> | annevk: which is why the problem only shows up in CHrome when you use specific functions |
| 22:15 | <annevk> | Domenic_: sure, some platform APIs use the settings object |
| 22:16 | <annevk> | Domenic_: but they do not have the right context to set it correctly |
| 22:19 | <annevk> | Domenic_: anyway, you should probably discuss this with bz_moz |
| 22:28 | <annevk> | Domenic_: http://esdiscuss.org/topic/realm-api-and-this-global |
| 22:29 | <annevk> | I wonder where that double newline came from |
| 22:30 | <Domenic_> | annevk: it's a bug in the esdiscuss.org scripts, happens whenever there's angle brackets in the line -_- |