/irc-logs / freenode / #whatwg / 2015-04-08 / end

Options:

# Session Start: Wed Apr 08 00:00:00 2015
# Session Ident: #whatwg
# [00:05] * Krinkle is now known as Krinkle|detached
# [00:06] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Read error: Connection reset by peer)
# [00:07] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
# [00:08] * Joins: jwalden (~waldo@216.3.171.26)
# [00:10] * Joins: jsbell (jsbell@nat/google/x-lkswotskrwfavapa)
# [00:14] * Quits: plutoniix (~plutoniix@node-1a3k.pool-101-109.dynamic.totbb.net) (Quit: จรลี จรลา)
# [00:22] * Quits: ehsan (~ehsan@66.207.208.102) (Remote host closed the connection)
# [00:24] * Quits: bzed (~bzed@devel.recluse.de) (Read error: Connection reset by peer)
# [00:24] * Joins: bzed (~bzed@devel.recluse.de)
# [00:27] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [00:30] * Quits: newtron (~newtron@199.71.174.203) (Quit: Leaving...)
# [00:30] * Joins: mven (~textual@cpe-72-183-104-138.austin.res.rr.com)
# [00:30] * Quits: mven (~textual@cpe-72-183-104-138.austin.res.rr.com) (Excess Flood)
# [00:32] * Joins: benwerd_ (~benwerd@178.62.73.90)
# [00:32] * Quits: benwerd (~benwerd@199.87.84.238) (Read error: Connection reset by peer)
# [00:32] * Joins: benwerd (~benwerd@199.87.84.238)
# [00:32] * Quits: Joseph_Silber (~JosephSil@ool-43513ca2.dyn.optonline.net) (Ping timeout: 244 seconds)
# [00:35] * Joins: rcombs (~rcombs@rcombs.me)
# [00:35] <wanderview> Domenic: has the performance impact of always returning a Promise from read() and write() been discussed somewhere?
# [00:36] <Domenic> wanderview: yeah. promises are cheap when well-optimized, and certainly cheaper than I/O.
# [00:36] * Quits: benwerd_ (~benwerd@178.62.73.90) (Ping timeout: 265 seconds)
# [00:37] <wanderview> Domenic: I guess I'm curious about how one optimizes out the object creation and the required async micro-task cost... it seems those are harder things to optimize out than say the generator object creation
# [00:38] * heycam|away is now known as heycam
# [00:38] <Domenic> wanderview: yeah you don't optimize out object creation, but VMs are good at creating objects. The micro-task cost we discussed and eventually landed on the fact that most reads are going to be async anyway, so the microtask adds no extra overhead.
# [00:38] <wanderview> Domenic: I mean.. I'm willing to accept Promise costs periodically... but once every 4096 bytes may be a bit much...
# [00:39] <wanderview> Domenic: in the case where you have chunks buffered up... it seems like you would want to be able to get all of them synchronously, though... no?
# [00:39] <Domenic> right, that was the original design with while (rs.state === "readable") { rs.read(); }
# [00:39] <Domenic> (read() being sync in that case)
# [00:39] <wanderview> Domenic: I vaguely remember that... what was the issue that forced the change?
# [00:41] <Domenic> wanderview: a combination of wanting rs.readInto(buffer) + non-epoll streams who do their work in a threadpool or similar means you need something like async read(), or setAllocator
# [00:41] <wanderview> Domenic: is ReadableByteStream or the new precise-flow-control stuff solving this by letting me say "read up to this much data before resolving"?
# [00:41] <Domenic> Unclear how setAllocator would work though given that I/O is IPC though, now that I think about it
# [00:42] <wanderview> Domenic: I/O doesn't have to be IPC... you can open a file descriptor in the parent and then dup(2) it to the child process... then file reads are in the child process
# [00:42] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [00:42] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [00:42] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:42] <Domenic> wanderview: the intent of ReadableByteStream's read(view) is that view.byteLength is at least a hint, although I think we didn't want to make it binding...
# [00:42] <wanderview> Domenic: network is probably always in the parent process behind IPC, though (because of http 1.1 channels multiplexed on same socket, etc)
# [00:42] <Domenic> wanderview: ah OK, just was thinking of the other day when you were talking about IPC costs...
# [00:43] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 250 seconds)
# [00:43] <Domenic> my vision of read(view) was that you'd pass that view pretty directly to read(2)
# [00:43] <Domenic> so for socket streams you might get back less than view.byteLength
# [00:43] <Domenic> but for file streams, unless you're at end of file, you'll probably get view fully filled
# [00:43] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [00:44] <Domenic> IIRC read(2) has an option to not return until the buffer is filled ... but it doesn't work with nonblocking sockets?
# [00:44] <Domenic> Ah no, it's recv(2). MSG_WAITALL
# [00:45] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [00:46] <Domenic> we could make the implementation concatenate buffers i guess? or let that be an option!? i don't see any reason why it's impossible, I was just going for the more direct mapping
# [00:47] <Domenic> it's a latency vs. efficiency thing i guess, which perhaps is best to leave to applications to decide?
# [00:48] <wanderview> sorry, on phone
# [00:48] <Domenic> np
# [00:48] <Domenic> reminds me of this issue https://github.com/whatwg/streams/issues/171
# [00:50] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
# [00:51] <Domenic> It is true in general that browser promise impls are wildly unoptimized. User-land versions regularly achieve 4x performance and 1/4th the memory consumption, and they don't even have access to all the tricks browsers do (like skipping the microtask queue if calling in from C++)
# [00:51] <wanderview> Domenic: I wonder if we could do something like .read(numDesiredChunks)
# [00:52] <wanderview> and the promise resolves when that many are available
# [00:52] <Domenic> wanderview: that seems pretty reasonable. Would kind of want to see data that this was a bottleneck, or a non-performance use case, before doing so.
# [00:53] <Domenic> I'll file an issue to track to see if anyone has non-perf use cases
# [00:53] <wanderview> Domenic: it seems more appropriate for ReadableByteStream... but might be usable in ReadableStream
# [00:54] <Domenic> wanderview: maybe for RBS it's .read(view, { waitUntilFull: true })
# [00:54] <wanderview> Domenic: thinking of when you are reading some framed protocol... you probably don't want to get woken up until the next frame is completely there
# [00:54] <wanderview> Domenic: I don't think c++ can skip the microtask, can it? I mean.. it seems like it risks accidentally breaking the micro task guarantee in your API
# [00:56] <Domenic> wanderview: it's hard to say precisely what I mean here as the area is so complicated. But the main idea is that C++ always enters back into JS from a clean stack, and that's what microtasks guarantee: a clean stack. One way of seeing this is that the very first thing done after transitioning from C++ to JS is to exhaust the microtask queue. So the very
# [00:56] <Domenic> first thing that happens on the JS side, after doing resolve_promise_from_cpp(cpp_p, cpp_v), is calling p's onFulfilled handler with v
# [00:57] <Domenic> IIUC SpiderMonkey doesn't actually implement a microtask queue and just uses their task queue, so maybe it is not so efficient in SpiderMonkey.
# [00:58] * Joins: scor (~scor@drupal.org/user/52142/view)
# [00:59] <wanderview> Domenic: right... but its still an async runnable even if it skips to the head of the (micro)task queue
# [00:59] <othermaciej> the spec says to drain the microtask queue between every regular task queue item
# [00:59] <othermaciej> (if I read it correctly)
# [01:00] <wanderview> and I guess unwinding and rewinding the stack has noticeable perf impacts when done in too tight a loop
# [01:00] <othermaciej> and after completing execution of a <script> element
# [01:00] <othermaciej> I don’t believe it says to do anything on entry from C++ to JS
# [01:00] * Joins: KevinMarks_ (~KevinMark@sjspeed.wiline.com)
# [01:01] <othermaciej> it might be you can do it like that and have no observable behavior difference but it is not obvious how offhand
# [01:02] <othermaciej> in particular, you can exit JS to C++ and re-enter JS sometimes without having performed microtasks
# [01:02] <Domenic> othermaciej: hmm, maybe i am confused. But that was my interpretation of the spec, modulo the spec not having any "entry from C++ to JS" concept.
# [01:02] <Domenic> Oh, that makes sense
# [01:02] <othermaciej> this will occur if you have multiple event handlers for the same event, for instance
# [01:02] <Domenic> Or just arr.forEach(cb), where hypothetically forEach is implemented in C++.
# [01:02] * Joins: satazor (~satazor@117.195.115.89.rev.vodafone.pt)
# [01:03] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [01:03] <othermaciej> the spec is closer to saying that microtasks are run on *exit* from JS to C++, except only if you are on a “clean stack”
# [01:03] <othermaciej> where “clean” == in the top level event loop or in the html parser
# [01:04] <othermaciej> and also it sometimes drains the queue on times you didn’t just exit from JS, in case right when you exited, you did not have a clean stack
# [01:04] <othermaciej> that is how I understand it anyway
# [01:05] * Krinkle|detached is now known as Krinkle
# [01:05] <Domenic> I guess the point I was really trying to make was: in Node.js, if you do `fs.readFile(..., result => resolvePromise(p, result))`, resolvePromise has to actually schedule a microtask to ensure p's handlers are called with a clean stack. So we wait for all the rest of the JS in that event loop turn to run, then unwind the stack, then run the microtask queue,
# [01:05] <Domenic> with several (perf-impacting) C++-to-JS transitions. Whereas in browsers, you don't have to pay that cost.
# [01:06] <Domenic> JS environments which try to completely control the event queue, like Angular, do similar optimizations
# [01:07] <Domenic> where they technically run their promise handlers "sync" but if you're programming correctly-according-to-Angular, it's unobservable.
# [01:07] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
# [01:11] * Joins: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net)
# [01:15] * Krinkle is now known as Krinkle|detached
# [01:21] * Krinkle|detached is now known as Krinkle
# [01:21] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
# [01:22] <wanderview> Domenic: are you trying to add an interface contract definition for ReadableStream and WritableStream in this issue? https://github.com/whatwg/streams/issues/312
# [01:23] <Domenic> wanderview: that thread has lost me a bit tbh...
# [01:23] <wanderview> Domenic: I think it would be really helpful to have definitions of ReadableStream and WritableStream separate from the default implementation adapting JS functions
# [01:25] <Domenic> wanderview: all ReadableStream instances must necessarily adapt JS functions (or JS manifestations of C++ functions)... other things obeying the "readable stream contract" might work differently though
# [01:25] <Domenic> the necessity is because myFetchReadableStream.read === myFileReadableStream.read, if both variables are ReadableStreams.
# [01:26] <wanderview> Domenic: so a DOM created ReadableStream representing some C++ implementation like a file stream has to be created through the ReadableStream Constructor?
# [01:26] <wanderview> Domenic: why is myFetchReadableStream.read === myFileReadableStream.read a necessity?
# [01:26] <Domenic> wanderview: I mean, it has to obey the observable invariants; if there are tricks you have for getting around that, use them, but...
# [01:27] <Domenic> wanderview: if they are both ReadableStreams then they have the same prototype and thus the same method
# [01:27] <Domenic> wanderview: if one is a FetchReadableStream and another is a FileReadableStream then yeah they can be different
# [01:27] <Domenic> wanderview: analogy---promises
# [01:27] <Domenic> wanderview: all C++-created promises are, at least in V8/Blink, created "via the Promise constructor"
# [01:27] <wanderview> Domenic: I guess what I am saying is, it would be nice if the spec defined the observable invariants instead of making me try to dig them out of a pile of js
# [01:28] <Domenic> even though the promises will be backed by very different behavior
# [01:28] <Domenic> yeah, agreed on that. We want that anyway so we can say---or better, programatically test---that ReadableByteStream behaves the same as ReadableStream.
# [01:28] <Domenic> the templated tests are a start
# [01:30] * Joins: eBureau (~Bruno@181.164.77.172)
# [01:31] * Krinkle is now known as Krinkle|detached
# [01:32] <wanderview> Domenic: so you are saying you want JS-created ReadableStream objects to have exactly the same prototype as DOM API created ReadableStream objects?
# [01:33] <Domenic> wanderview: yeah, exactly, just like Promise.
# [01:33] <wanderview> Domenic: pretend I don't know much about Promise :-)
# [01:34] <Domenic> hmm, well, then, yes. The underlying source is meant to provide the customization hooks
# [01:34] <Domenic> The underlying source could be a JS facade over a C++ object, for sure
# [01:34] <wanderview> Domenic: I guess then it would be nice to have a source interface definition... and separate out the js-adapter specifics into a separate implementation of that interface
# [01:35] * Joins: rcombs (~rcombs@rcombs.me)
# [01:35] <Domenic> hmm what's a "source interface definition"?
# [01:35] <wanderview> Domenic: the underlying source
# [01:35] <Domenic> https://streams.spec.whatwg.org/#rs-constructor kind of tries
# [01:36] <Domenic> what are js-adapter specifics? there are no implementations of the underlying source interface in the streams spec
# [01:36] <Domenic> fetch-with-streams has one
# [01:36] <wanderview> Domenic: nm... I don't think what I asked makes sense
# [01:37] <wanderview> Domenic: do you anticipate things like ReadableStream.pipeTo() operating on the public ws.write() method? so allowing monkey patching
# [01:38] <wanderview> the current text pointing at the ref implementation suggests it does
# [01:38] <Domenic> An implementation could always do something like ReadableStream.prototype.read = function () { switch (this@[[hiddenType]]) { case "user-created": return userCreatedImpl(this); case "fetch": return fetchStreamImpl(this); } }; where user-created follows more or less the exact spec algorithm and fetchStreamImpl manages to maintain all its observable invariants
# [01:38] <Domenic> but is implemented differently.
# [01:39] <Domenic> Then we have to tease out what the observable invariants are. I guess maybe that's what you're asking for.
# [01:39] <wanderview> Domenic: I'm asking about monkey-patching .write in this case
# [01:39] <Domenic> sorry I was still on the previous subject
# [01:39] <wanderview> but I guess .read is the same
# [01:39] * Quits: benwerd (~benwerd@199.87.84.238)
# [01:40] <wanderview> Domenic: I think the "underlying source" model maps reasonably well to the DOM idiom of having an "inner object"
# [01:40] <Domenic> hmm interesting
# [01:40] <wanderview> but I guess DOM APIs typically operate explicitly on the inner objects... not on the public APIs
# [01:40] <Domenic> Ah interesting
# [01:40] <wanderview> so rs.pipe(ws) would do something like "write data to ws's underlying sink" instead of calling ws.write()
# [01:41] <Domenic> regarding monkey-patching write and pipeTo... I'm a bit torn on how to handle this. I've probably given up on it using `this.read()` etc.; it can use tamper-proof versions for operating on `this` to reduce complexity. But it seems quite important to allow polymorphic dispatch on the *argument*.
# [01:41] <wanderview> Domenic: the polymorphism is achieved in this spec by swapping out the underlying sink, no?
# [01:41] <Domenic> That said as we went through in some thread a while ago it's hard to make that work while still allowing unobservable off-main-thread piping
# [01:42] <Domenic> wanderview: heh, I guess that is where my argument leads...
# [01:42] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
# [01:42] <Domenic> wanderview: my hope was that you could create structurally similar writable streams that obey the same contract without being exactly WritableStreams
# [01:42] <wanderview> Domenic: going to the inner objects is nice for DOM people like me... but I wonder if its not very javascripty
# [01:42] <Domenic> Yeah, it's definitely not very JavaScriptey. But neither is off-main-thread piping :P
# [01:42] <wanderview> Domenic: that seems at odds with requiring prototypes to be exact matches
# [01:43] <Domenic> wanderview: nothing requires the prototypes to be exact matches, I was just saying, if they are, then they need to be the same impl
# [01:43] <wanderview> Domenic: if you want pure duck types then I don't think we should require exact prototype matches
# [01:43] <Domenic> wanderview: you *could* have separate FetchReadableStream that is written from scratch in its own spec and doesn't reference the stream spec at all, except trying to be duck-compatible.
# [01:43] <Domenic> But that seems like a waste of effort.
# [01:43] <wanderview> Domenic: like... I think the JS adapter stuff should be in a JSReadableStream that chains from ReadableStream, etc
# [01:44] <Domenic> Anyway, my hope might be silly, is where I was going with that.
# [01:44] <wanderview> and there is no spec'd concrete implementation of ReadableStream
# [01:44] <Domenic> This just feels very silly when you go back to the promise analogy
# [01:45] <Domenic> We don't have every promise-returning API on the web platform creating their own version of the Promise class just so they can get different backing behavior
# [01:45] <wanderview> Domenic: I don't think we have the optimization concerns with off-main-thread piping, etc, with Promises that we do here...
# [01:45] * Quits: bholley (~bholley@50.174.198.217)
# [01:45] <wanderview> something has to give here :-) I don't think all these requirements are compatible
# [01:46] <Domenic> I am leaning toward abandoning duck-compatibility for writable streams
# [01:46] <wanderview> Domenic: what about for ReadableStreams?
# [01:47] <Domenic> wanderview: unsure, nothing accepts them right now (except their own methods, and JS functions which will operate on a duck level)
# [01:47] <wanderview> Domenic: but their own methods will operate directly on underlying source?
# [01:47] <Domenic> wanderview: yeah, definitely.
# [01:48] <wanderview> Domenic: is there an existing issue for this or shall I write a new one?
# [01:48] <Domenic> wanderview: well, I was for a while planning on making pipeTo operate in terms of this.read() and friends, but after doing TeeReadableStream I am leaning away from that.
# [01:48] <wanderview> I think it was partially discussed in the transfer issue, but seems it deserves its own issue
# [01:48] <Domenic> wanderview: we kind of got sidetracked in the ... web socket issue, was it? into these
# [01:48] <Domenic> ah yeah
# [01:48] <wanderview> Domenic: I'll write one
# [01:49] <Domenic> ok cool
# [01:49] <Domenic> Hmm, promises enable duck-compatibility with Promise.resolve casting .then'ables ..... that's a more sound model actually. Also a complicated one that we probably don't need to build in to the platform?
# [01:50] <Domenic> It should be pretty straightforward to write a JS function duckReadableStreamToRealReadableStream
# [01:50] <Domenic> Then people can use that if they need to
# [01:50] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [01:51] <wanderview> Domenic: I do think a ReadableStream wrapper constructor would be nice... making it take a duck typed stream would be reasonably
# [01:51] <Domenic> The promise-esque alternative being that we have ReadableStream.cast = duckReadableStreamToRealReadableStream and every ReadableStream-accepting API does ReadableStream.cast first (like all promise-accepting APIs do Promise.resolve first). Really unnecessary.
# [01:52] <Domenic> brb cafe closing!!
# [01:52] * wanderview forgot he was in pacific time zone.
# [01:53] * Quits: jernoble (~jernoble@17.202.49.155) (Quit: Computer has gone to sleep.)
# [01:53] * Quits: jwalden (~waldo@216.3.171.26) (Quit: about to board, see you once in the sky)
# [01:54] * Joins: rcombs (~rcombs@rcombs.me)
# [01:55] * Quits: satazor (~satazor@117.195.115.89.rev.vodafone.pt) (Remote host closed the connection)
# [02:02] * Joins: eBureau (~Bruno@181.164.77.172)
# [02:03] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
# [02:04] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [02:04] * Joins: scor (~scor@drupal.org/user/52142/view)
# [02:06] * Quits: ap (~ap@17.114.216.168)
# [02:07] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
# [02:07] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [02:10] * Quits: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e) (Ping timeout: 245 seconds)
# [02:12] <Domenic> ok, back, although i should probably head out for the day
# [02:12] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [02:13] <terinjokes> Domenic: you should go home
# [02:13] <Domenic> this Promise.resolve analogy soothes me greatly
# [02:13] <Domenic> (in general any time I can analogy to promises, I feel more confident)
# [02:14] <Domenic> we can let pipeTo only accept true WritableStreams, and if in the future that becomes limiting we can add WritableStream.cast or similar as a mechanism for coping
# [02:16] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
# [02:20] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Ping timeout: 250 seconds)
# [02:21] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
# [02:21] <wanderview> Domenic: https://github.com/whatwg/streams/issues/321
# [02:21] <wanderview> have a good night!
# [02:24] * Quits: jyasskin (~jyasskin@216.239.45.64) (Quit: My computer has gone to sleep. ZZZzzz…)
# [02:26] * Joins: rcombs (~rcombs@rcombs.me)
# [02:26] * Joins: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca)
# [02:27] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
# [02:28] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
# [02:28] * Quits: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca) (Remote host closed the connection)
# [02:29] * Quits: jsbell (jsbell@nat/google/x-lkswotskrwfavapa) (Quit: There's no place like home...)
# [02:29] * Joins: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca)
# [02:31] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
# [02:31] * Joins: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th)
# [02:31] * Quits: ehsan (~ehsan@ip-162-250-172-185.fibre.fibrestream.ca) (Client Quit)
# [02:32] * Joins: mven (~textual@cpe-72-183-104-138.austin.res.rr.com)
# [02:32] * Quits: mven (~textual@cpe-72-183-104-138.austin.res.rr.com) (Excess Flood)
# [02:38] * Quits: bzed (~bzed@devel.recluse.de) (Remote host closed the connection)
# [02:41] * Joins: bzed (~bzed@devel.recluse.de)
# [02:42] * Joins: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [02:42] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 272 seconds)
# [02:43] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
# [02:44] * Joins: jwalden (~waldo@67.142.235.252)
# [02:45] * Quits: bnicholson (~bnicholso@2620:101:80fc:224:d1a2:1dd0:3450:b5cf) (Quit: This computer has gone to sleep)
# [02:46] * Quits: jacobolu_ (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [02:46] * Joins: rcombs (~rcombs@rcombs.me)
# [02:46] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [02:56] * Quits: rcombs (~rcombs@rcombs.me) (Ping timeout: 245 seconds)
# [02:57] * Joins: rcombs (~rcombs@rcombs.me)
# [02:57] * Joins: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net)
# [02:57] * Joins: jyasskin (~jyasskin@216.239.45.64)
# [03:01] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-tpiowtciyqvrzpzh) (Quit: Connection closed for inactivity)
# [03:04] * Quits: othermaciej (~mjs@17.244.161.57) (Quit: othermaciej)
# [03:04] * Quits: KevinMarks_ (~KevinMark@sjspeed.wiline.com) (Ping timeout: 250 seconds)
# [03:10] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: Textual IRC Client: www.textualapp.com)
# [03:12] * Quits: jyasskin (~jyasskin@216.239.45.64) (Quit: My computer has gone to sleep. ZZZzzz…)
# [03:13] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [03:17] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [03:17] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [03:17] * Joins: scor (~scor@drupal.org/user/52142/view)
# [03:18] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [03:19] * Joins: weinig (~weinig@17.244.160.230)
# [03:23] * Joins: othermaciej (~mjs@76.74.153.41)
# [03:30] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
# [03:30] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
# [03:31] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Client Quit)
# [03:31] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
# [03:31] * Joins: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp)
# [03:38] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [03:43] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:44] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:51] * Joins: scor (~scor@drupal.org/user/52142/view)
# [03:56] * Joins: svl (~me@200.123.210.20)
# [03:57] * Quits: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402) (Ping timeout: 265 seconds)
# [03:57] * Joins: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402)
# [03:57] * Quits: iamstef (sid12605@gateway/web/irccloud.com/x-iozjblydqusrmjjq) (Ping timeout: 265 seconds)
# [03:57] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-umlrbilawxeqxtwm) (Ping timeout: 265 seconds)
# [03:57] * Quits: parshap (sid18846@gateway/web/irccloud.com/x-qtjrafxbnoaqnudr) (Ping timeout: 265 seconds)
# [03:57] * Quits: ato (sid16069@gateway/web/irccloud.com/x-csfyqyroxqqulajk) (Ping timeout: 265 seconds)
# [03:58] * Quits: arv (sid4269@gateway/web/irccloud.com/x-jobczpfaxqxqjygr) (Ping timeout: 265 seconds)
# [03:58] * Joins: ato (sid16069@gateway/web/irccloud.com/x-ukkfrhsyfivwdmdz)
# [03:58] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 265 seconds)
# [03:59] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-hpiomwiwhdqxlgju) (Ping timeout: 265 seconds)
# [03:59] * Quits: svl (~me@200.123.210.20) (Read error: Connection reset by peer)
# [04:00] * Joins: arv (sid4269@gateway/web/irccloud.com/x-eorwzpxtjneavgjl)
# [04:01] * Joins: JonathanNeal (sid5831@gateway/web/irccloud.com/x-fuxitvwitojnboku)
# [04:01] * Joins: iamstef (sid12605@gateway/web/irccloud.com/x-ymqpvjqghqivufvi)
# [04:01] * Joins: parshap (sid18846@gateway/web/irccloud.com/x-aobwogvcedhpopls)
# [04:02] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-uzxurnbyhpawtjai)
# [04:05] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [04:06] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
# [04:08] * Quits: jwalden (~waldo@67.142.235.252) (Quit: landing, g'bye)
# [04:12] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
# [04:13] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [04:21] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
# [04:23] * Joins: svl (~me@200.123.210.20)
# [04:25] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-uzxurnbyhpawtjai) (Quit: Connection closed for inactivity)
# [04:29] * Quits: plutoniix (~plutoniix@ppp-115-87-213-193.revip4.asianet.co.th) (Read error: Connection reset by peer)
# [04:31] * Joins: plutoniix (~plutoniix@ppp-58-11-121-178.revip2.asianet.co.th)
# [04:31] * Quits: weinig (~weinig@17.244.160.230) (Quit: weinig)
# [04:43] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [04:58] * Quits: svl (~me@200.123.210.20) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [05:04] * heycam is now known as heycam|away
# [05:09] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [05:10] * Joins: xiinotulp (~plutoniix@119.63.87.222)
# [05:12] * Quits: plutoniix (~plutoniix@ppp-58-11-121-178.revip2.asianet.co.th) (Ping timeout: 250 seconds)
# [05:14] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 252 seconds)
# [05:18] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
# [05:18] * xiinotulp is now known as plutoniix
# [05:23] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [05:27] * Joins: weinig (~weinig@c-98-234-191-242.hsd1.ca.comcast.net)
# [05:28] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 245 seconds)
# [05:31] * Joins: eBureau (~Bruno@181.164.77.172)
# [05:32] * Quits: weinig (~weinig@c-98-234-191-242.hsd1.ca.comcast.net) (Quit: weinig)
# [05:43] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [05:47] * Quits: rniwa (~rniwa@17.245.30.85) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [05:48] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 245 seconds)
# [05:53] * heycam|away is now known as heycam
# [05:54] * Joins: jyasskin (~jyasskin@172.56.38.23)
# [06:02] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [06:27] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
# [06:31] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [06:36] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 265 seconds)
# [06:38] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
# [06:38] * Joins: jyasskin (~jyasskin@172.56.38.23)
# [06:57] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 250 seconds)
# [06:58] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 244 seconds)
# [07:00] * Joins: jyasskin (~jyasskin@172.56.38.23)
# [07:01] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:09] * Joins: ^esc (~esc-ape@77.119.129.86.wireless.dyn.drei.com)
# [07:11] * Quits: jyasskin (~jyasskin@172.56.38.23) (Ping timeout: 250 seconds)
# [07:12] * Quits: ^esc_ (~esc-ape@91.141.0.146.wireless.dyn.drei.com) (Ping timeout: 264 seconds)
# [07:17] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 256 seconds)
# [07:18] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 265 seconds)
# [07:18] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:20] * Joins: hgl (~hgl@unaffiliated/hgl)
# [07:21] * Quits: beverloo (beverloo@nat/google/x-evgnfcezfeuubipj) (Ping timeout: 256 seconds)
# [07:22] * Joins: karlcow (~karl@nerval.la-grange.net)
# [07:23] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 256 seconds)
# [07:25] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:25] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Max SendQ exceeded)
# [07:25] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:25] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Max SendQ exceeded)
# [07:26] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:26] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 272 seconds)
# [07:28] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [07:31] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 255 seconds)
# [07:33] * Joins: beverloo (beverloo@nat/google/x-oeiuycibigsenuli)
# [07:38] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [07:40] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [07:40] * Quits: KevinMarks (~yaaic@2607:fb90:515:f7fd:b63c:d5fd:e9ef:19f4) (Ping timeout: 245 seconds)
# [07:59] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-nhdglwyqqzkwtyhk) (Quit: Connection closed for inactivity)
# [08:01] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [08:03] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [08:06] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [08:07] * Joins: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net)
# [08:13] * Joins: KevinMarks (~yaaic@2607:fb90:22cf:3e:3247:fe5f:f03e:11d3)
# [08:16] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [08:16] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
# [08:28] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:33] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [08:34] <JakeA> annevk: https://github.com/slightlyoff/ServiceWorker/issues/607#issuecomment-90819078 - I don't understand "wait with overrideRequestURL"
# [08:42] * heycam is now known as heycam|away
# [08:47] * Joins: markkes (~markkes@62.207.90.201)
# [08:50] <annevk> JakeA: just not implement it
# [08:51] <annevk> JakeA: what you argue for would be a new special case that did not exist before; the case the implementers brought up was not considered when we figured it as a shorthand for short-circuiting redirects
# [08:52] * Quits: mpt (~mpt@canonical/mpt) (Remote host closed the connection)
# [08:53] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
# [08:55] <JakeA> annevk: we've got some internal customers for this, I'll find out if the API works for them. But yeah, in that case it isn't exactly like a redirect.
# [08:55] <annevk> JakeA: it would be interesting to hear why they can't use Response.redirect()
# [08:58] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
# [08:59] * Joins: mpt (~mpt@canonical/mpt)
# [09:02] <JakeA> annevk: yeah, I'm digging into that and building them an example
# [09:02] * Quits: dshwang (~dshwang@192.55.54.36) (Remote host closed the connection)
# [09:03] * Joins: dshwang (~dshwang@192.55.54.36)
# [09:06] * Quits: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64) (Remote host closed the connection)
# [09:08] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-klwoysokbwvhatmi)
# [09:22] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [09:23] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [09:23] * Joins: hasather (~hasather@80.91.33.141)
# [09:24] * Quits: KevinMarks (~yaaic@2607:fb90:22cf:3e:3247:fe5f:f03e:11d3) (Ping timeout: 245 seconds)
# [09:28] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [09:30] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
# [09:36] * Joins: Ms2ger (~Ms2ger@193.190.253.150)
# [09:40] * Joins: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
# [09:57] <annevk> Is anyone using https://atom.io/?
# [10:01] * Quits: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 264 seconds)
# [10:12] * Quits: abarth (sid5294@gateway/web/irccloud.com/x-pgwwpidtkiwrrypa) (Ping timeout: 256 seconds)
# [10:13] * c74d is now known as Guest42134
# [10:13] * Joins: abarth (sid5294@gateway/web/irccloud.com/x-xiccuqxrdtvqosfj)
# [10:13] * Quits: remysharp (sid4345@gateway/web/irccloud.com/x-htkrakyoltfkvkvi) (Ping timeout: 256 seconds)
# [10:13] * Quits: Guest42134 (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Ping timeout: 256 seconds)
# [10:14] * Joins: remysharp (sid4345@gateway/web/irccloud.com/x-zvcynrkwvslzrzyu)
# [10:17] * Joins: satazor (~satazor@117.195.115.89.rev.vodafone.pt)
# [10:22] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
# [10:25] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [10:31] * Quits: satazor (~satazor@117.195.115.89.rev.vodafone.pt) (Remote host closed the connection)
# [10:38] <philipj> annevk: I think the general situation is that Content-Type is ignored for both media elements and <track>
# [10:39] <philipj> there's a bit of a history, but since Microsoft caved and started ignoring it in IE I think there's no turning back (which I'm happy about)
# [10:39] <annevk> philipj: so for X-Content-Type-Options: nosniff we want to give server administrators the feature of enforcing Content-Type for resources so they can't be used in an unexpected context
# [10:40] <annevk> philipj: this requires a whitelist of MIME types for audio/video and a separate set for track
# [10:40] <philipj> uh, ok, I couldn't say how that currently works
# [10:41] <annevk> philipj: it doesn't for those contexts
# [10:41] <annevk> philipj: well, it might in IE
# [10:41] <annevk> I haven't tested IE yet
# [10:41] <philipj> for <track> there's just no code that looks at Content-Type, at least not in Blink, if it's not WebVTT then it won't work
# [10:56] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
# [10:59] * Quits: 6JTAAT81B (~scrollbac@gateway/web/scrollback.io/x-ezmprbpfafhspsfx) (Ping timeout: 252 seconds)
# [11:00] * Joins: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr)
# [11:04] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:04] * Joins: karlcow (~karl@nerval.la-grange.net)
# [11:04] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [11:09] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Remote host closed the connection)
# [11:09] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:14] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 256 seconds)
# [11:15] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [11:15] * Quits: tripu (~tripu@p7223-ipngn11001marunouchi.tokyo.ocn.ne.jp) (Quit: Leaving)
# [11:19] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:21] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [11:25] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:30] <annevk> philipj: okay, so we could just make the whitelist text/webvtt
# [11:30] <annevk> philipj: for CSS it's text/css at the moment
# [11:30] <annevk> philipj: only unclear thing then is the MIME types for audio/video which is somewhat of a trainwreck
# [11:31] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Ping timeout: 256 seconds)
# [11:34] * Joins: satazor (~satazor@bl6-111-97.dsl.telepac.pt)
# [11:37] * Quits: satazor (~satazor@bl6-111-97.dsl.telepac.pt) (Read error: Connection reset by peer)
# [11:42] <annevk> text/vtt*
# [11:46] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 255 seconds)
# [11:47] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:51] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [11:54] <annevk> http://w3cdreams.tumblr.com/
# [11:55] * Joins: jamesheston (~jameshest@wsip-98-173-32-122.sd.sd.cox.net)
# [11:57] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [11:58] <jgraham> Wow, well I was enjoying that and then the Service Worker thing guenuninely made me feel ill
# [11:59] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [12:05] * Joins: satazor (~satazor@bl6-111-97.dsl.telepac.pt)
# [12:07] <annevk> jgraham: hypno cat?
# [12:08] * Quits: satazor (~satazor@bl6-111-97.dsl.telepac.pt) (Read error: Connection reset by peer)
# [12:09] <jgraham> Possibly
# [12:10] <jgraham> Also made me unable to spell genuinely
# [12:14] <zcorpan> just need to let the eyes follow the circles a few laps and then you'll feel better again
# [12:14] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [12:15] * Quits: plutoniix (~plutoniix@119.63.87.222) (Quit: จรลี จรลา)
# [12:19] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [12:19] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [12:19] * Joins: scor (~scor@drupal.org/user/52142/view)
# [12:20] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [12:20] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [12:31] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [12:35] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [12:41] * Joins: satazor (~satazor@114.248.108.93.rev.vodafone.pt)
# [12:45] * Quits: satazor (~satazor@114.248.108.93.rev.vodafone.pt) (Read error: Connection reset by peer)
# [12:56] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [12:57] * Quits: jamesheston (~jameshest@wsip-98-173-32-122.sd.sd.cox.net) (Quit: Textual IRC Client: www.textualapp.com)
# [12:57] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-dxjhreefmwsgkaqr)
# [13:11] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [13:13] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-ijppgawzergdqrxb)
# [13:14] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [13:29] * Joins: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek)
# [13:40] * Quits: eric_carlson (~ericc@c-24-6-239-9.hsd1.ca.comcast.net) (Quit: eric_carlson)
# [13:45] * Joins: scor (scor@nat/acquia/x-lkuznhmniecwxuhl)
# [13:45] * Quits: scor (scor@nat/acquia/x-lkuznhmniecwxuhl) (Changing host)
# [13:45] * Joins: scor (scor@drupal.org/user/52142/view)
# [13:50] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 240 seconds)
# [13:54] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
# [13:56] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [13:59] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 264 seconds)
# [13:59] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [14:00] * Joins: sarri (~sari@p50995cae.dip0.t-ipconnect.de)
# [14:00] * Quits: sarri (~sari@p50995cae.dip0.t-ipconnect.de) (Changing host)
# [14:00] * Joins: sarri (~sari@unaffiliated/sarri)
# [14:16] * Joins: Kolombiken (~Adium@94.137.124.2)
# [14:33] * Joins: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi)
# [14:36] * Joins: plutoniix (~plutoniix@node-krx.pool-101-108.dynamic.totbb.net)
# [14:43] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 245 seconds)
# [14:44] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [14:49] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [14:52] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 252 seconds)
# [14:55] * Joins: hgl (~hgl@unaffiliated/hgl)
# [14:57] * Joins: r2 (~r2@200.80.227.70)
# [14:59] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [15:01] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
# [15:02] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [15:05] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-dxjhreefmwsgkaqr) (Quit: Connection closed for inactivity)
# [15:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Remote host closed the connection)
# [15:08] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [15:11] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [15:15] * Quits: g4 (~g4@unaffiliated/gormer) (Remote host closed the connection)
# [15:18] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [15:23] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
# [15:27] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-wmjnceqrtmnuhbzo)
# [15:27] * Joins: ato_ (~sid11@2620:101:8016:74::4:b)
# [15:27] * Quits: ato (sid16069@gateway/web/irccloud.com/x-ukkfrhsyfivwdmdz)
# [15:27] * ato_ is now known as ato
# [15:31] * Joins: newtron (~newtron@199.71.174.203)
# [15:33] * Joins: g4 (~g4@unaffiliated/gormer)
# [15:34] * Joins: jsx (uid48919@fsf/intern/jsx)
# [15:37] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Quit: Leaving...)
# [15:38] * Joins: TallTed (~Thud@63.119.36.36)
# [15:41] * Joins: wilsonpage (~wilsonpag@94.118.128.13)
# [15:43] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
# [15:50] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 240 seconds)
# [15:53] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [15:53] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
# [15:54] * Joins: karlcow (~karl@nerval.la-grange.net)
# [15:56] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 245 seconds)
# [15:57] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
# [15:58] * Joins: hgl (~hgl@unaffiliated/hgl)
# [15:59] * Joins: eric_carlson (~ericc@17.202.49.252)
# [16:01] * Joins: eBureau (~Bruno@181.164.77.172)
# [16:08] * Joins: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [16:09] * Joins: boogyman__ (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263)
# [16:09] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Ping timeout: 256 seconds)
# [16:11] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (Ping timeout: 245 seconds)
# [16:11] * boogyman__ is now known as boogyman
# [16:11] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Ping timeout: 256 seconds)
# [16:11] * boogyman is now known as Guest37534
# [16:12] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
# [16:12] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
# [16:16] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
# [16:22] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Ping timeout: 244 seconds)
# [16:23] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [16:23] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: The deeper I go / the deeper I go / green mountains - Santoka)
# [16:24] * Joins: karlcow (~karl@nerval.la-grange.net)
# [16:24] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [16:24] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
# [16:30] * Joins: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com)
# [16:31] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Remote host closed the connection)
# [16:32] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 255 seconds)
# [16:34] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
# [16:36] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [16:38] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
# [16:40] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [16:49] <wanderview> Domenic: you said there were user space Promise libs that were faster than browser implementations... can you point me at one you recommend for perf?
# [16:49] <bradleymeck> wanderview: bluebird
# [16:50] <Domenic> yep
# [16:51] * Quits: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com) (Ping timeout: 256 seconds)
# [16:53] <wanderview> Domenic: should I just be able to drop this in with the stream reference impl?
# [16:53] * Joins: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com)
# [16:54] <Domenic> wanderview: ugh, the reference impl is so un-optimized...
# [16:54] <Domenic> wanderview: but, yeah, if you do global.Promise = require('bluebird') it should be drop-in-able
# [16:55] <Domenic> But I mean, all the asserts (in loops too!) and try/catches and the hilarious queue-with-sizes implementation will dwarf the performance change I think
# [16:59] <wanderview> Domenic: meeting now... but I'll try to describe the case I'm concerned with... I can write something not use ref impl, but just something similar to tease out the Promise impact
# [16:59] * Joins: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net)
# [16:59] * Joins: ehsan_ (~ehsan@67.213.81.142)
# [17:00] <Domenic> wanderview: OK cool. Be sure it does actual I/O too :)
# [17:01] <wanderview> Domenic: javascript consumers may not do actual I/O
# [17:01] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-klwoysokbwvhatmi) (Quit: Connection closed for inactivity)
# [17:02] <Domenic> Ultimately the stream should be grounded in some I/O, most likely
# [17:03] <Domenic> E.g. maybe your stream vends JS objects but it's derived from some stream that read from a file/network
# [17:07] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [17:08] * Quits: markkes (~markkes@62.207.90.201) (Quit: markkes)
# [17:10] * Quits: hasather (~hasather@80.91.33.141) (Read error: Connection reset by peer)
# [17:12] * Joins: hasather (~hasather@80.91.33.141)
# [17:12] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Read error: Connection reset by peer)
# [17:13] * Joins: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com)
# [17:15] * Quits: g4 (~g4@unaffiliated/gormer) (Quit: Leaving)
# [17:19] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [17:22] * Joins: eBureau (~Bruno@181.164.77.172)
# [17:23] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [17:26] * Quits: bnicholson (~bnicholso@230.sub-70-197-21.myvzw.com) (Quit: This computer has gone to sleep)
# [17:30] * Joins: hemanth (~hemanth@122.167.67.18)
# [17:33] <wanderview> Domenic: is it not reasonable for js to do in-memory operations like your stream demo where its searching for a particular value? that is not I/O related
# [17:33] * Quits: ehsan_ (~ehsan@67.213.81.142) (Remote host closed the connection)
# [17:34] <Domenic> wanderview: how is that no I/O related?
# [17:34] <Domenic> wanderview: the stream is a fetch stream
# [17:34] * Joins: KevinMarks (~yaaic@2607:fb90:5c4:383:ff43:1a9:f55f:1b6b)
# [17:34] <wanderview> Domenic: I thought you meant on the consumption side you wanted it to be I/O
# [17:34] <Domenic> wanderview: oh, no, i just meant that each promise produced from the reader should correspond to doing some I/O
# [17:35] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [17:35] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-wmjnceqrtmnuhbzo) (Quit: Connection closed for inactivity)
# [17:36] <Domenic> i.e., don't test for (let i = 0; i < 1000; ++i) { Promise.resolve(5).then(foo); }; test for (let i = 0; i < 1000; ++i) { fs.read(fd, ...).then(foo); })
# [17:36] <wanderview> Domenic: the main case I can think of that concerns me is where you write data to a pipe buffer... and then want to read it starting at some later time... in that case the pipe .read() is not related to I/O until the buffer is drained... and draining the buffer will be much slower than with sync .read()
# [17:36] * Joins: hasather (~hasather@80.91.33.141)
# [17:36] * Joins: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [17:36] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [17:36] <Domenic> "much" slower citation needed... especially since sync read() would need to use async .ready or similar for backpressure signals
# [17:36] <wanderview> Domenic: thats why I want to test with real Promises :-)
# [17:37] <Domenic> sounds good :)
# [17:37] <wanderview> Domenic: I agree at least one async operation is needed... but doing it on every buffered chunk seems potentially not good
# [17:38] <wanderview> Domenic: I'm going to put this in the batch read issue... I think some kind of .readAllAvailable() would solve this... give me an array of all available chunks... so you get an array of length 1 or greater
# [17:38] * Quits: KevinMarks (~yaaic@2607:fb90:5c4:383:ff43:1a9:f55f:1b6b) (Ping timeout: 245 seconds)
# [17:38] <wanderview> for cases where you just want to read as fast as possible
# [17:38] <Domenic> wanderview: sounds good, yeah. Or 0 chunks if end of stream.
# [17:40] * Joins: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [17:43] * Quits: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
# [17:46] * Joins: KevinMarks__ (~yaaic@2607:fb90:5a4:3009:490a:16c7:81b7:fdcd)
# [17:48] * Quits: KevinMarks_ (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 244 seconds)
# [17:49] <wanderview> Domenic: I guess my concern here started by looking at the current rs.pipeTo() implementation... since it waits for each .read() to resolve before calling .read() again... you can't get any pipelining going that way... and then I started to wonder if it should do two .read() calls... so while its writing the first its already started the async process to get
# [17:49] <wanderview> the next, etc
# [17:49] * Quits: KevinMarks (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
# [17:50] <Domenic> wanderview: right, but that should only delay at most a microtask, and then it will resolve and immediately call read() again, and the stack only has to unwind one frame since we're already in the microtask loop... it's one extra frame per loop iteration basically.
# [17:55] * Joins: svl (~me@200.123.210.20)
# [17:56] * Quits: bradleymeck (~bradleyme@rrcs-71-41-188-164.sw.biz.rr.com) (Quit: bradleymeck)
# [17:56] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (Ping timeout: 256 seconds)
# [17:57] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [17:57] * Joins: jdaggett_ (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp)
# [17:57] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [17:59] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [17:59] <JakeA> wanderview: I've been thinking about cache.add[All]. I've been seeing a lot of examples check the status code of responses before putting them into the cache. Maybe we should revisit the idea of checking response.ok before caching (as an option). This would of course fail on all opaque responses. Do you think it's still useful?
# [18:02] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Read error: Connection reset by peer)
# [18:02] <wanderview> JakeA: in a meeting
# [18:02] <JakeA> no rush
# [18:03] * Joins: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca)
# [18:03] * Joins: adactio (~adactio@212.42.170.121)
# [18:03] * Quits: Areks (~Areks@rs.gridnine.com) (Ping timeout: 272 seconds)
# [18:06] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [18:06] * Joins: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com)
# [18:06] * Joins: ap (~ap@17.202.44.214)
# [18:09] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-ncoqwrllfdpdgzzg)
# [18:11] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [18:17] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [18:19] * Joins: eBureau (~Bruno@181.164.77.172)
# [18:19] * Quits: hemanth (~hemanth@122.167.67.18) (Quit: This computer has gone to sleep)
# [18:29] * Joins: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net)
# [18:30] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [18:38] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [18:41] * Quits: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [18:43] * Joins: ehsan_ (~ehsan@2001:450:1f:224:d4de:dec7:880f:bcc7)
# [18:44] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-jncnmqtebpqdprfm)
# [18:47] * Joins: mikenovikov (~mikenovik@ip-95-220-98-138.bb.netbynet.ru)
# [18:52] * Joins: KevinMarks (~KevinMark@172.56.16.98)
# [18:53] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
# [18:53] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [18:59] * Quits: sicking (~sicking@c-98-210-159-193.hsd1.ca.comcast.net) (Quit: sicking)
# [19:01] * Quits: adactio (~adactio@212.42.170.121) (Quit: adactio)
# [19:01] * Krinkle|detached is now known as Krinkle
# [19:02] * Quits: jdaggett_ (~jdaggett@ad056175.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett_)
# [19:03] <annevk> JakeA: should it not be added to fetch() then?
# [19:05] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [19:07] * Quits: zcorpan (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Read error: Connection reset by peer)
# [19:07] * Joins: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com)
# [19:08] * Quits: KevinMarks (~KevinMark@172.56.16.98) (Ping timeout: 250 seconds)
# [19:12] <wanderview> JakeA: that sounds fine to me... I don't really have an opinion... whatever developers want/expect
# [19:12] * Quits: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com) (Quit: Leaving)
# [19:12] <wanderview> not sure I understand the opaque response thing, though
# [19:12] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [19:12] * Quits: zcorpan_ (~zcorpan@90-230-218-37-no135.tbcn.telia.com) (Ping timeout: 255 seconds)
# [19:12] <annevk> Domenic: the post-ES6 specification plan sounds rather lovely
# [19:12] * Joins: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com)
# [19:12] <Domenic> :)
# [19:12] <Domenic> we'll see if we can pull it off...
# [19:13] <annevk> Domenic: I wonder if WHATWG can gradually convert to that as well
# [19:13] <wanderview> what plan?
# [19:13] <annevk> wanderview: https://esdiscuss.org/topic/the-great-tooling-revolution
# [19:16] * Joins: iandevlin (~iandevlin@dslb-088-070-108-065.088.070.pools.vodafone-ip.de)
# [19:16] <Domenic> annevk: you mean the two-impls thing?
# [19:16] <annevk> Domenic: the tooling and writing style
# [19:16] <Domenic> annevk: ah interesting.
# [19:16] * Joins: eBureau (~Bruno@181.164.77.172)
# [19:16] * Quits: iandevlin (~iandevlin@dslb-088-070-108-065.088.070.pools.vodafone-ip.de) (Client Quit)
# [19:16] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [19:16] <annevk> having said that, ES6 is rather hard to digest, but some of the algorithm shorthands you're introducing seem nice
# [19:16] <Domenic> Yeah, I was going to say, "Ecmaspeak"'s evolution into something more user-friendly is still in progress (cf. https://streams.spec.whatwg.org/#conventions)
# [19:16] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [19:16] <Domenic> And it's unclear the value of Ecmaspeak vs. some kind of "spec ES"
# [19:17] <wanderview> Domenic: what does chrome's shipping Response body stream do for a Response returned from cache.match()? does it stream from disk?
# [19:17] <Domenic> wanderview: good... question...... tyoshino are you awake perchance?
# [19:17] <wanderview> I mean... is that implemented in this first version
# [19:17] <Domenic> oh hi yhirano_ is in here too
# [19:18] <Domenic> Maybe the thing to do is ask on the blink-dev Intent to Ship thread?
# [19:19] * Quits: othermaciej (~mjs@c-71-198-213-78.hsd1.ca.comcast.net) (Quit: othermaciej)
# [19:19] * Joins: hemanth (~hemanth@122.167.67.18)
# [19:20] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [19:20] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
# [19:23] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [19:24] <wanderview> Domenic: ok, will do... mainly just curious
# [19:25] <wanderview> Domenic: what is WritableStream.getWriter() you to mention in that issue update? I don;t see that in the spec
# [19:26] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
# [19:28] * Joins: othermaciej (~mjs@76.74.153.41)
# [19:31] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [19:33] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [19:42] * Joins: KevinMarks (~KevinMark@sjspeed.wiline.com)
# [19:54] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [19:54] * Joins: hasather (~hasather@80.91.33.141)
# [19:57] <Domenic> wanderview: https://github.com/whatwg/streams/issues/319 :-S
# [19:57] <wanderview> ok... so not spec'd yet
# [19:57] <wanderview> wasn't sure if it was coming or previous-and-gone
# [19:58] <Domenic> heh... yeah
# [19:58] <Domenic> wanderview: related https://github.com/whatwg/streams/commit/d757e05cf27f73488d13825e51ce5706a759ab27
# [20:01] <wanderview> Domenic: I didn't want to bikeshed more in the "getReader is named poorly" issue... but take() is also widely used for locking concepts :-)
# [20:05] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
# [20:06] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
# [20:06] * Quits: wilsonpage (~wilsonpag@94.118.128.13) (Quit: My Mac has gone to sleep. ZZZzzz…)
# [20:06] <Domenic> meeeeeeeeeeehhhhhh
# [20:08] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [20:09] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [20:09] <wanderview> Domenic: getReader() does not unlock if the reader gets GC'd right? or rather, the whole stream has to be GC'd in addition to the reader?
# [20:09] <Domenic> wanderview: right. (and in the latter case i'm not sure there's a difference.)
# [20:10] <Domenic> wanderview: webkit has a test showing this
# [20:10] <Domenic> unsure how/whether to put it in the general suite...
# [20:10] * Quits: svl (~me@200.123.210.20) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
# [20:11] <wanderview> Domenic: I really dislike stuff with explicit release like revokeObjectUrl()... so many leaks in code that use them... the error paths are atrocious
# [20:11] <wanderview> from my experience with code in fxos trying to use that kind of API
# [20:11] <Domenic> wanderview: well this case is pretty different, since it's not like you could successfully get another reader by waiting for GC of the first one, since that's unreliable
# [20:12] <Domenic> that's a fair argument for the lifecycle management thread though
# [20:12] <wanderview> yea
# [20:12] <wanderview> I think I mentioned it there
# [20:13] <wanderview> Domenic: is there a finally thing on promises for people to always return the reader?
# [20:13] <wanderview> maybe that makes it less of a problem
# [20:13] * Quits: espadrine (~tyl@LMontsouris-656-1-2-84.w80-12.abo.wanadoo.fr) (Ping timeout: 265 seconds)
# [20:14] <Domenic> wanderview: we've been wanting to add finally to promises for a long time, and this cancelable promise stuff might push it over the line.
# [20:16] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Ping timeout: 265 seconds)
# [20:16] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Quit: Leaving...)
# [20:16] <wanderview> Domenic: I guess its not a huge problem here... since lock is released automatically on close
# [20:16] <wanderview> its optimized for single reader case... which is what we want
# [20:17] * Quits: karlcow (~karl@nerval.la-grange.net) (Ping timeout: 256 seconds)
# [20:20] * Joins: karlcow (~karl@nerval.la-grange.net)
# [20:21] * Quits: KevinMarks__ (~yaaic@2607:fb90:5a4:3009:490a:16c7:81b7:fdcd) (Ping timeout: 245 seconds)
# [20:21] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [20:21] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [20:21] <Domenic> wanderview: yeah, that's kind of the idea. if anyone's doing something tricky like parsing a header portion then passing the partially-read stream on to someone else, they can probably remember to release the lock. Although I agree finally would be nice.
# [20:21] * Joins: KevinMarks__ (~yaaic@2607:fb90:5ca:3eb:1d11:c7f0:4077:e151)
# [20:22] <wanderview> Domenic: that seems like something easier down with pipeThrough()... although it would be nice to remove the header transform piece after its done
# [20:22] <Domenic> hmm yeah that's true
# [20:23] <wanderview> ^down^done
# [20:23] <Domenic> i guess most uses of readers are hidden behind the higher-level methods like pipe*() and tee()
# [20:27] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
# [20:29] * Quits: KevinMarks__ (~yaaic@2607:fb90:5ca:3eb:1d11:c7f0:4077:e151) (Ping timeout: 245 seconds)
# [20:32] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [20:34] * Joins: rniwa (~rniwa@17.245.30.85)
# [20:35] * Quits: othermaciej (~mjs@76.74.153.41) (Quit: othermaciej)
# [20:35] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
# [20:38] * Quits: hemanth (~hemanth@122.167.67.18) (Quit: This computer has gone to sleep)
# [20:38] * Joins: rniwa (~rniwa@17.245.30.85)
# [20:38] * Joins: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com)
# [20:38] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
# [20:39] <calvaris> sorry, I just fell and I don't know if you read what I said but
# [20:39] <calvaris> wanderview: I have a pull request with that test
# [20:39] <calvaris> all custom tests that we had for WK are now there and waiting for Domenic to merge them
# [20:40] <wanderview> calvaris: which test?
# [20:41] * Joins: othermaciej (~mjs@17.244.160.90)
# [20:41] <calvaris> the one for the garbage collection regarding the reader
# [20:41] <wanderview> Domenic: btw, we apparently do implement microtask queue in gecko now
# [20:41] <wanderview> calvaris: ah, cool
# [20:42] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
# [20:42] <Domenic> wanderview: ah that's excellent
# [20:42] <wanderview> Domenic: I still don't think our c++ can optimize around them, though... since js can call into c++ with js still on the stack
# [20:43] * Joins: benwerd (~benwerd@199.87.84.238)
# [20:46] * Joins: josemanuel (~josemanue@6.27.11.37.dynamic.jazztel.es)
# [20:47] * Joins: Maurice` (~copyman@unaffiliated/maurice)
# [20:48] * Guest37534 is now known as boogyman
# [20:48] * Quits: boogyman (~boogyman@2601:0:b801:ad00:2ca0:cc55:6594:d263) (Changing host)
# [20:48] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [20:49] * Joins: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e)
# [20:49] * Quits: bnicholson (~bnicholso@corp-nat.p2p.sfo1.mozilla.com) (Quit: This computer has gone to sleep)
# [20:50] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [20:54] * Quits: hasather (~hasather@80.91.33.141) (Remote host closed the connection)
# [20:55] * Joins: hasather (~hasather@80.91.33.141)
# [20:55] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-jncnmqtebpqdprfm) (Quit: Connection closed for inactivity)
# [20:58] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
# [20:58] * Joins: rniwa (~rniwa@17.245.30.85)
# [20:59] * Quits: rniwa (~rniwa@17.245.30.85) (Client Quit)
# [21:01] * Quits: r2 (~r2@200.80.227.70) (Read error: Connection reset by peer)
# [21:02] * Joins: KevinMarks__ (~yaaic@2607:fb90:5c8:ef08:c85e:14ca:36b6:26da)
# [21:02] * Joins: othermaciej (~mjs@17.244.160.90)
# [21:04] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: No route to host)
# [21:05] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
# [21:06] * Quits: KevinMarks__ (~yaaic@2607:fb90:5c8:ef08:c85e:14ca:36b6:26da) (Ping timeout: 245 seconds)
# [21:07] * Joins: rniwa (~rniwa@17.245.30.85)
# [21:09] * Quits: eric_carlson (~ericc@17.202.49.252) (Quit: eric_carlson)
# [21:11] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [21:12] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
# [21:12] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
# [21:12] * Joins: scor (~scor@drupal.org/user/52142/view)
# [21:13] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [21:14] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [21:15] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [21:16] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [21:16] * Joins: scor (~scor@drupal.org/user/52142/view)
# [21:17] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [21:17] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 252 seconds)
# [21:19] * Joins: hgl (~hgl@unaffiliated/hgl)
# [21:22] * Quits: calvaris (~calvaris@254.126.27.77.dynamic.mundo-r.com) (Ping timeout: 240 seconds)
# [21:23] * Krinkle is now known as Krinkle|detached
# [21:25] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
# [21:25] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
# [21:25] * Joins: scor (~scor@drupal.org/user/52142/view)
# [21:25] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-plqsjkpysnzhgwvh)
# [21:26] * Quits: scor (~scor@drupal.org/user/52142/view) (Client Quit)
# [21:28] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
# [21:28] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
# [21:28] * Joins: scor (~scor@drupal.org/user/52142/view)
# [21:29] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: Connection reset by peer)
# [21:29] * Quits: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3) (Quit: installing updates'n'stuff, back shortly)
# [21:30] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
# [21:31] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 244 seconds)
# [21:34] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [21:36] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
# [21:36] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Max SendQ exceeded)
# [21:36] * Joins: eric_carlson (~ericc@17.202.49.252)
# [21:36] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
# [21:36] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Client Quit)
# [21:38] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
# [21:38] * Quits: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net) (Max SendQ exceeded)
# [21:39] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [21:40] * Joins: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
# [21:40] * Parts: program247365 (~program24@pool-108-55-27-133.bflony.fios.verizon.net)
# [21:41] * Joins: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net)
# [21:41] * Quits: scor (~scor@c-98-216-67-164.hsd1.ma.comcast.net) (Changing host)
# [21:41] * Joins: scor (~scor@drupal.org/user/52142/view)
# [21:41] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
# [21:42] * Joins: othermaciej (~mjs@17.244.160.90)
# [21:43] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
# [21:44] * Joins: othermaciej (~mjs@17.244.160.90)
# [21:50] * Quits: othermaciej (~mjs@17.244.160.90) (Quit: othermaciej)
# [21:50] * Quits: scor (~scor@drupal.org/user/52142/view) (Quit: scor)
# [21:50] * Joins: othermaciej (~mjs@17.244.160.90)
# [21:51] * Quits: zenith_ (~zenith@user3-81-244.wireless.utoronto.ca) (Remote host closed the connection)
# [21:54] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
# [21:56] <trevnorris> Domenic: "Cheaper than I/O" doesn't say a lot and Promise instantiation speed isn't the only thing to consider. It's the complete time from .push() to .read().
# [21:56] * Joins: bnicholson (~bnicholso@2620:101:80fb:224:f422:186:fa95:1a4c)
# [21:56] * Joins: othermaciej (~mjs@17.244.160.90)
# [21:57] * Quits: othermaciej (~mjs@17.244.160.90) (Client Quit)
# [21:57] * Joins: jwalden (~waldo@2620:101:80fc:224:7e7a:91ff:fe25:a5a3)
# [22:00] * Joins: othermaciej (~mjs@17.244.160.90)
# [22:07] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Quit: bradleymeck)
# [22:09] * Quits: Kolombiken (~Adium@94.137.124.2) (Quit: Leaving.)
# [22:11] * Joins: zenith_ (~zenith@142.150.23.90)
# [22:16] * Joins: ato_ (sid16069@gateway/web/irccloud.com/x-schsaawoueitwdop)
# [22:18] * Quits: eric_carlson (~ericc@17.202.49.252) (Ping timeout: 252 seconds)
# [22:18] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 244 seconds)
# [22:18] * Quits: ato_ (sid16069@gateway/web/irccloud.com/x-schsaawoueitwdop) (Client Quit)
# [22:19] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [22:19] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [22:19] * Joins: KevinMarks (~KevinMark@sjspeed.wiline.com)
# [22:19] * Joins: eric_carlson (~ericc@17.202.49.94)
# [22:19] * Quits: lnr (~lnr@aim.engr.arizona.edu) (Ping timeout: 240 seconds)
# [22:20] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [22:21] * Joins: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net)
# [22:21] * Quits: scor (~scor@c-24-2-162-32.hsd1.ma.comcast.net) (Changing host)
# [22:21] * Joins: scor (~scor@drupal.org/user/52142/view)
# [22:22] * Joins: benwerd_ (~benwerd@178.62.0.159)
# [22:22] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [22:22] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [22:24] * Quits: benwerd (~benwerd@199.87.84.238) (Ping timeout: 245 seconds)
# [22:24] * Joins: espadrine (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [22:26] * Joins: benwerd (~benwerd@199.87.84.238)
# [22:27] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [22:30] * Quits: benwerd_ (~benwerd@178.62.0.159) (Ping timeout: 252 seconds)
# [22:30] * Joins: hasather_ (~hasather@cm-84.210.170.16.getinternet.no)
# [22:34] * Quits: zdobersek (~zan@gateway/vpn/privateinternetaccess/zdobersek) (Quit: Leaving.)
# [22:36] * Joins: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com)
# [22:39] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
# [22:42] * Quits: SteveF_ (~chatzilla@cpc3-nmal20-2-0-cust916.19-2.cable.virginm.net) (Ping timeout: 250 seconds)
# [22:42] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [22:48] * Quits: eric_carlson (~ericc@17.202.49.94) (Ping timeout: 250 seconds)
# [22:49] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: My iMac has gone to sleep. ZZZzzz…)
# [22:59] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [23:04] * Quits: Ms2ger (~Ms2ger@193.190.253.150) (Quit: nn)
# [23:04] * Quits: smaug____ (~chatzilla@62-78-246-79.bb.dnainternet.fi) (Ping timeout: 245 seconds)
# [23:07] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
# [23:09] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [23:10] * Quits: dbaron (~dbaron@2620:101:80fb:224:2d19:d044:d21e:612e) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [23:11] * Joins: dbaron (~dbaron@guest-nat.p2p.sfo1.mozilla.com)
# [23:12] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
# [23:12] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
# [23:14] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net) (Quit: ZZZzzz…)
# [23:14] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
# [23:15] * Quits: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net) (Client Quit)
# [23:18] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Read error: Connection reset by peer)
# [23:19] * Joins: KevinMarks_ (~yaaic@sjspeed.wiline.com)
# [23:19] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [23:20] <wanderview> Domenic: what does it mean for a ReadableStream to .pipeTo() a WritableByteStream... what if the RS produces non-byte things?
# [23:20] <Domenic> wanderview: calling .write() (or the equivalent internal operation if we move to that model) will error, causing the pipe to error.
# [23:21] <wanderview> Domenic: but if the ReadableStream passes Uint8Array chunks, then its ok?
# [23:21] <Domenic> wanderview: yes, I would really like that to work
# [23:22] <Domenic> wanderview: maybe allow any of the "BufferView" types
# [23:22] * Quits: TallTed (~Thud@63.119.36.36)
# [23:22] <wanderview> or just ArrayBuffer, I presume?
# [23:23] * Quits: hasather_ (~hasather@cm-84.210.170.16.getinternet.no) (Remote host closed the connection)
# [23:24] * Quits: Maurice` (~copyman@unaffiliated/maurice)
# [23:25] <Domenic> wanderview: right, I forgot what the type was called that is a union of all typed arrays + ArrayBuffer + DataView
# [23:25] * Quits: josemanuel (~josemanue@6.27.11.37.dynamic.jazztel.es) (Quit: Saliendo)
# [23:26] <Domenic> "BufferSource" apparently
# [23:26] * Quits: KevinMarks (~KevinMark@sjspeed.wiline.com) (Ping timeout: 248 seconds)
# [23:27] <wanderview> Domenic: where is the latest ReadableByteStream proposal?
# [23:27] <Domenic> wanderview: https://github.com/whatwg/streams/blob/asyncbytestream/BinaryExtension.md
# [23:27] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
# [23:29] * Joins: KevinMarks (~yaaic@sfspeed.wiline.com)
# [23:29] <wanderview> Domenic: so... its starting to feel to me like we should not have a ReadableByteStream at all... if the underlying source of the stream operates on bytes, then the specialization has already occurred... getReader() can just return a ByobReader
# [23:29] <wanderview> or am I missing something?
# [23:29] <TabAtkins> bring-your-own-beerReader
# [23:29] * Quits: KevinMarks_ (~yaaic@sjspeed.wiline.com) (Ping timeout: 252 seconds)
# [23:30] * wanderview didn't name it. :-)
# [23:30] <wanderview> ByobByteStreamReader
# [23:31] * Joins: KevinMarks_ (~yaaic@2607:fb90:538:fe9e:b14f:3c3b:7fa7:b398)
# [23:31] <Domenic> wanderview: hmm, but adding the BYOB layer changes things quite a lot, adding complexity specifically for the byte case. You would advocate building that complexity into the readable stream itself?
# [23:32] <wanderview> Domenic: if a view is not passed to .read()... can it not just do a "get me the next chunk" semantics pretty easily?
# [23:32] <trevnorris> Domenic: spec probably can't define any implementation details, can it?
# [23:32] <Domenic> wanderview: for example the underlying source needs some kind of hook read(view) -> promise that fills view, and inside the stream/reader mechanisms you need something such that byobReader.read(view) transfers view to view2 then passes view2 to the read hook on the source
# [23:32] <Domenic> trevnorris: it can define anything observable
# [23:33] <Domenic> trevnorris: including creation APIs
# [23:33] * Quits: KevinMarks (~yaaic@sfspeed.wiline.com) (Ping timeout: 245 seconds)
# [23:33] <Domenic> wanderview: the idea is you should opt in to one mode or the other (BYOB or auto-flowing)
# [23:34] <wanderview> Domenic: then keep it getByobReader(), but have it reject on streams that don't have the right underlying source
# [23:34] <Domenic> for example BYOB doesn't have a high water mark or queue in general (although it does probably keep one around since kernel buffers are finite... unsure if that's observable to spec or can be part of the underlying source details)
# [23:34] <Domenic> wanderview: ick, that's a very bad API. It would be like Node having a tagName that throws an exception when you try to use it on Comment nodes
# [23:34] <trevnorris> Domenic: my implementations tie a C++ class to every JS stream, on which a class method can be defined to receive incoming data. .pipe() can detect that and short circuit the JS call by passing from the internal C++ to the implementation defined method.
# [23:35] <trevnorris> unfortunately it depends on certain V8-isms that i'm not sure are currently possible in other engines.
# [23:35] <Domenic> trevnorris: right, in that case the spec's job is to make your short circuit unobservable
# [23:35] <Domenic> trevnorris: and that means completely unobservable, even if someone overwrites dest.write to log when called or similar ;)
# [23:35] <wanderview> Domenic: what does ReadableByteStream get you beyond the Byob capacility? It doesn't seem like anything... so maybe it should be a ByobReadableStream
# [23:36] <Domenic> wanderview: yes, that is indeed the real delta. We figured it was a more user-friendly name? But no real opposition to renaming it
# [23:36] <wanderview> Domenic: I guess the problem with that is the producer of the stream does not know if the user wants Byob semantics
# [23:36] <Domenic> Actually we are kind of hoping not to use the term "BYOB" in public API. The fact that's in tyoshino's doc is largely just as a placeholder :)
# [23:36] <wanderview> ^user^consumer
# [23:37] <wanderview> I know
# [23:37] <wanderview> Domenic: it just feels the "type" of the stream is determined by the underlying source... and having to have a special shell around particular underlying sources is clumsy... ReadableStream should just enable the extra features if its constructed with a byte oriented underlying source
# [23:37] <Domenic> wanderview: the hope is that it is efficient for streams like fetch/fs/etc. that are bytes-backed to implement ReadableByteStream, and then consumers who want to opt in to BYOB behavior can use .getByobReader(), and normal people (including those agnostic to the chunk type) can just use .getReader()
# [23:38] * Quits: mrbkap (~mrbkap@63.245.214.133) (Quit: leaving)
# [23:38] <Domenic> wanderview: I don't agree with that. The logical conclusion of that argument is that streams should be able to bake me a cake if I give them the right underlying source.
# [23:39] <Domenic> Adding fundamentally new capabilities, instead of just different behavior, should require a new type.
# [23:39] * wanderview likes cake.
# [23:39] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
# [23:39] <wanderview> Domenic: what do you anticipate being different about a WritableByteStream?
# [23:40] <Domenic> wanderview: hazy right now, but one big thing is it will need to detach any passed-in buffers since they might be sent off thread
# [23:41] <wanderview> Domenic: that... seems hard without including it in the WritableStream contract
# [23:41] <Domenic> hmm how so?
# [23:42] <wanderview> Domenic: isn't that an optimizaiton that should be negotiated by native underlying source to native underlying sink?
# [23:42] <Domenic> wanderview: I am talking about var a = new Uint8Array([5, 10, 15, 20]); fileStream.write(a)
# [23:43] <Domenic> I want to send the backing memory of a off into the thread that does file I/O
# [23:43] <Domenic> and I am pretty sure we don't want to let people do a[0] = 7 and have that mutate the memory, maybe before the write, maybe after the write
# [23:43] <wanderview> Domenic: you're talking about effectively making the chunk disappear from content... if under normal circumstances I can do ws.write(chunk); muchAroundWithChunk(chunk); ... how will code based just on WritableStream know that .write() suddently doesn't work that way because it has a WBS?
# [23:44] <wanderview> Domenic: I guess I'm saying WritableStream.write() contract should say "don't expect the chunk to exist in its current form after this call" regardless of WritableStream vs WritableByteStream
# [23:44] * Joins: jernoble (~jernoble@17.202.46.221)
# [23:44] <Domenic> wanderview: that's fair, although I'm not sure in practice how worried we should be. But one easy fix is to add .getTransferringWriter() or similar, whereas .getWriter() does copies?? I dunno.
# [23:45] <Domenic> wanderview: I just have no idea how to enforce that contract
# [23:45] <Domenic> if it's not true for most writable streams, then people might assume it, no matter if the spec has some kind of "don't assume this please" note.
# [23:45] <wanderview> Domenic: maybe its not enforceable... but we can at least say "told you so" when people' stuff breaks :-)
# [23:45] <Domenic> heh, ok
# [23:46] <wanderview> Domenic: it just seems stuff like ByobReader and maybe this TransferringWriter are opportunistic things... optimize in this fashion if its available... otherwise use the lesser stuff
# [23:46] <wanderview> Domenic: and I guess in your mind the right way to "check if its available" is to do an instanceof on the prototype?
# [23:47] <Domenic> wanderview: I don't see how to make ByobReader opportunistic. E.g. no way to do https://gist.github.com/domenic/65921459ef7a31ec2839#reading-a-file-chunkwise (old API I think) without explicitly doing things with JS
# [23:47] <Domenic> wanderview: check if what is available?
# [23:47] <wanderview> Domenic: check if ByobReader is available on a RS, for example
# [23:47] <Domenic> wanderview: if (rs.getByobReader) { ... }
# [23:50] <wanderview> Domenic: can't see much difference between that and getByobReader() returning null if its not supported
# [23:50] <Domenic> wanderview: it's just basic API design... we don't add everything onto a single object. New classes of objects get ... new classes.
# [23:50] <Domenic> Node vs. Element, etc.
# [23:50] <wanderview> Domenic: I think I dislike mixing that with the revealing constructor pattern... the constructor is not revealing all the behavior
# [23:51] <wanderview> Domenic: if we had a revealing factory method that could construct the right type... it might seem a bit better to me
# [23:51] <Domenic> wanderview: I don't see how they're related. Revealing constructor pattern lets you customize a type's behavior. You can have different revealing constructors for different types. We don't use the same type for Promise and ReadableStream, even though they both have customizable behavior via the revealing constructor pattern.
# [23:51] <Domenic> why would you say the constructor is not revealing all the behavior?
# [23:52] <wanderview> Domenic: why would you ever do new ReadableStream(myByteSource)? shouldn't you *always* do new ReadableByteStream(myByteSource)?
# [23:52] <Domenic> wanderview: yes?
# [23:53] <Domenic> did i say otherwise?
# [23:53] <wanderview> Domenic: no... but it feels weird to leave that as a footgun for people
# [23:53] <Domenic> it's the same footgun as new Promise(myByteSource) ... not really worried.
# [23:53] <wanderview> the type is really associated with the source, not the wrapper object
# [23:53] <Domenic> or new WritableStream(myByteSource)
# [23:54] <wanderview> Domenic: except those will fail... ReadableStream(myByteSource) will work, but just prevent consumers from optimizing
# [23:54] <Domenic> The source is an adapter between the conceptual source and the concrete readable stream type
# [23:54] * Joins: bholley (~bholley@c-50-174-198-217.hsd1.ca.comcast.net)
# [23:54] <Domenic> wanderview: why would it work?
# [23:55] <wanderview> Domenic: err... from what I can tell new ReadableStream() and new ReadableByteStream() expect the same properties on the passed duck typed source?
# [23:55] <wanderview> is that not true?
# [23:55] <Domenic> wanderview: the argument for ReadableByteStream() is not specced at all yet :)
# [23:56] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [23:56] <Domenic> wanderview: it will probably be something like { start() { }, read(view), cancel(reason) { } }
# [23:56] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [23:57] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [23:57] <wanderview> ok
# [23:58] <wanderview> Domenic: going back to WritableByteStream... one optimization we have in our native streams is the writing side can pass its destination back into the person doing the write... so in theory this could be passed back to read(view) or something to all a ReadableByteStream to write directly into a WritableByteStream
# [23:59] <Domenic> wanderview: good point, i forgot that was also something we definitely want out of ReadableByteStream + WritableByteStream pipes
# Session Close: Thu Apr 09 00:00:00 2015

Think these logs are useful? Then please donate to show your gratitude (and keep them up, of course). Thanks! — Krijn