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

Options:

# Session Start: Mon Apr 06 00:00:00 2015
# Session Ident: #whatwg
# [00:07] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [00:13] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [00:14] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [00:15] * Joins: zama (~zama@unaffiliated/stryx/x-3871776)
# [00:21] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [00:37] * Quits: jsx (uid48919@fsf/intern/jsx) (Quit: Connection closed for inactivity)
# [00:43] * Quits: wnklb (~winklebee@p549E6518.dip0.t-ipconnect.de)
# [00:49] * Joins: svl (~me@200.123.210.20)
# [00:50] * Quits: svl (~me@200.123.210.20) (Client Quit)
# [00:52] * Quits: newtron (~newtron@206-248-160-177.dsl.teksavvy.com) (Remote host closed the connection)
# [01:17] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [01:20] <wanderview> annevk: only easter sunday
# [01:21] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [01:29] * Joins: newtron (~newtron@206-248-160-177.dsl.teksavvy.com)
# [01:31] * Parts: ori (~ori@wikipedia/ori-livneh) ("Leaving...")
# [01:37] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [01:38] <gsnedders> A properly defined grammar for the html5lib test format would be great, because dear god trying to parse this
# [01:39] <gsnedders> Pretty sure we're LR(2)
# [01:39] <gsnedders> At least in the simple definition
# [01:42] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 264 seconds)
# [01:56] * Joins: newtron_ (~newtron@206-248-160-177.dsl.teksavvy.com)
# [01:59] * Quits: newtron (~newtron@206-248-160-177.dsl.teksavvy.com) (Ping timeout: 252 seconds)
# [02:07] * Joins: KevinMarks_ (~yaaic@2607:fb90:53b:a816:1a3a:ef9c:2cdb:1b50)
# [02:08] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [02:12] * Quits: newtron_ (~newtron@206-248-160-177.dsl.teksavvy.com) (Remote host closed the connection)
# [02:18] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [02:22] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [02:24] * Krinkle is now known as Krinkle|detached
# [02:34] * Joins: mven_ (~textual@cpe-72-183-104-138.austin.res.rr.com)
# [02:34] * Quits: mven_ (~textual@cpe-72-183-104-138.austin.res.rr.com) (Excess Flood)
# [02:40] * Quits: seventh (seventh@192.64.7.137) (Quit: ...)
# [02:46] * Joins: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net)
# [02:46] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-whzznkannfhlraon)
# [02:50] * Joins: KevinMarks__ (~yaaic@2607:fb90:229f:d6dd:eb0a:166:41d8:94ab)
# [02:53] * Quits: KevinMarks_ (~yaaic@2607:fb90:53b:a816:1a3a:ef9c:2cdb:1b50) (Ping timeout: 265 seconds)
# [03:12] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:14] * Quits: KevinMarks__ (~yaaic@2607:fb90:229f:d6dd:eb0a:166:41d8:94ab) (Ping timeout: 256 seconds)
# [03:20] * Joins: falken (uid20729@gateway/web/irccloud.com/x-tzkkiacxmyzixedh)
# [03:23] * Joins: karlcow (~karl@nerval.la-grange.net)
# [03:26] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [03:31] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 272 seconds)
# [03:33] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [03:45] * Joins: KevinMarks__ (~yaaic@2607:fb90:2266:3f40:d3fa:ab10:8e:9a81)
# [03:46] * Joins: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:48] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 264 seconds)
# [03:50] * Quits: KevinMarks__ (~yaaic@2607:fb90:2266:3f40:d3fa:ab10:8e:9a81) (Ping timeout: 265 seconds)
# [03:50] * Joins: Goplat (~goplat@reactos/developer/Goplat)
# [03:56] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [03:57] * Quits: KevinMarks___ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
# [04:12] * Joins: benwerd (~benwerd@67.180.159.135)
# [04:25] * Joins: newtron (~newtron@206-248-160-177.dsl.teksavvy.com)
# [04:26] * Quits: benwerd (~benwerd@67.180.159.135)
# [04:46] * Quits: newtron (~newtron@206-248-160-177.dsl.teksavvy.com) (Remote host closed the connection)
# [05:05] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [05:05] * Quits: jonr22 (~jonr22@2601:6:8000:eaef:1e65:9dff:fe9d:801d) (Ping timeout: 256 seconds)
# [05:12] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Remote host closed the connection)
# [05:13] * Joins: ohaibbq (~ohaibbq@2601:9:a80:a8f:ed9d:13c4:c5cb:c97e)
# [05:15] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [05:15] * Joins: xCG (~CvP@203.76.123.238)
# [05:15] * Quits: CvP (~CvP@203.76.123.238) (Disconnected by services)
# [05:15] * xCG is now known as CvP
# [05:17] * Quits: ohaibbq (~ohaibbq@2601:9:a80:a8f:ed9d:13c4:c5cb:c97e) (Ping timeout: 256 seconds)
# [05:18] * Quits: CvP (~CvP@203.76.123.238) (Read error: Connection reset by peer)
# [05:19] * Joins: CvP (~CvP@203.76.123.238)
# [05:19] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 255 seconds)
# [05:20] * Quits: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (Read error: Connection reset by peer)
# [05:21] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [05:22] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [05:24] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
# [05:29] * Quits: jungkees (uid24208@gateway/web/irccloud.com/x-tjwpvhrcghxehyzd) (Quit: Connection closed for inactivity)
# [05:46] * Quits: Guest86102 (~tiago@bl5-180-217.dsl.telepac.pt) (Ping timeout: 272 seconds)
# [05:48] * Joins: tiago (~tiago@bl10-136-105.dsl.telepac.pt)
# [05:48] * tiago is now known as Guest72872
# [05:55] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [06:06] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [06:07] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [06:21] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [06:22] * Joins: technommy (~tommyliu@121.15.84.11)
# [06:25] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [06:27] * Quits: technommy (~tommyliu@121.15.84.11) (Ping timeout: 246 seconds)
# [06:28] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
# [06:28] * Joins: _ritchie_ (~andrewr@cpe-67-243-154-181.nyc.res.rr.com)
# [06:31] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Ping timeout: 256 seconds)
# [06:31] * Joins: technommy (~tommyliu@121.15.84.11)
# [06:53] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [06:58] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [07:04] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [07:06] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [07:08] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 246 seconds)
# [07:09] * Joins: karlcow (~karl@nerval.la-grange.net)
# [07:12] * Quits: technommy (~tommyliu@121.15.84.11) (Remote host closed the connection)
# [07:12] * Joins: technommy (~tommyliu@121.15.84.11)
# [07:13] * Quits: karlcow (~karl@nerval.la-grange.net) (Client Quit)
# [07:13] * Joins: karlcow (~karl@nerval.la-grange.net)
# [07:15] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-whzznkannfhlraon) (Quit: Connection closed for inactivity)
# [07:17] * Quits: technommy (~tommyliu@121.15.84.11) (Ping timeout: 256 seconds)
# [07:21] * Joins: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net)
# [07:37] * Quits: _ritchie_ (~andrewr@cpe-67-243-154-181.nyc.res.rr.com) (Quit: _ritchie_)
# [08:04] * Joins: technommy (~tommyliu@116.25.160.250)
# [08:08] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [08:13] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [08:24] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
# [08:39] * Joins: zdobersek (~zan@46.166.188.237)
# [08:41] <annevk> JakeA: is it not inconvenient that the Cache API does not allow things like .match(url, {headers:{x:"y"}})?
# [08:47] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [08:48] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 255 seconds)
# [08:51] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Ping timeout: 244 seconds)
# [08:52] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [08:53] * Quits: psy_ (~psy@103.6.159.177) (Ping timeout: 250 seconds)
# [08:57] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 250 seconds)
# [08:58] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [08:59] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [08:59] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [09:00] * Joins: ohaibbq (~ohaibbq@98.248.65.213)
# [09:02] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [09:03] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [09:06] * Joins: KevinMarks__ (~yaaic@2607:fb90:2283:e648:464b:49f8:d286:91ad)
# [09:09] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 272 seconds)
# [09:09] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [09:14] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [09:22] * Joins: roc_ (~chatzilla@121-99-129-246.bng1.tvc.orcon.net.nz)
# [09:22] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Quit: Leaving...)
# [09:24] * Quits: roc (~chatzilla@121-98-104-110.bng1.tvc.orcon.net.nz) (Ping timeout: 265 seconds)
# [09:24] * roc_ is now known as roc
# [09:26] <annevk> JakeA: wanderview: was it considered to allow more than http/https URLs in caches?
# [09:28] * Quits: karlcow (~karl@nerval.la-grange.net) (Quit: This computer has gone to sleep)
# [09:31] * Joins: viduthalai1947_ (uid5404@gateway/web/irccloud.com/x-yxecuezvfvnmwscs)
# [09:34] <JakeA> annevk: that stuff can be added. What use cases are you thinking? Are those matching request or response headers?
# [09:34] <annevk> JakeA: I mean constructing Request objects in the same way that fetch() allows for
# [09:34] <JakeA> annevk: nah, it follows http caching rules so it's pretty restricted to http
# [09:35] <annevk> JakeA: it doesn't really follow HTTP cache rules
# [09:35] <annevk> JakeA: perhaps HTTP cache matching rules
# [09:36] <annevk> JakeA: but we use HTTP headers and such for other schemes too, and if we allowed other schemes you could more easily abuse it as a key/value store
# [09:36] <JakeA> annevk: Ohh, so the API would be .match(url, requestOpt, queryOpts)?
# [09:36] <annevk> JakeA: yeah, I was wondering why that wasn't done
# [09:37] <JakeA> Having to include an empty object just to get at the query options sounds bad
# [09:38] <annevk> I guess it doesn't matter so much here to have an easy way to construct a Request object
# [09:39] <JakeA> annevk: if there's a way to add non-http in there, I'm cool with it. The way caching is designed is to ensure every item in the cache is matchable
# [09:40] <JakeA> Other than http/https, what were you thinking?
# [09:40] * Quits: brcweggs (~brcweggs@pool-71-177-224-47.lsanca.fios.verizon.net) (Quit: Lingo: www.lingoirc.com)
# [09:41] <annevk> I was initially thinking everything, but that doesn't work well. So maybe something like cachekey URLs (cachekey:item1)... Anyway, later seems fine
# [09:43] <annevk> What might also be cool is having a way to refer to Cache API objects from content without having to go through a service worker, but that might be harder for objects that require more than a URL to match on
# [09:44] <annevk> Or maybe it could be something like <script src=url from=cache>
# [09:45] <annevk> But that's also awfully similar to the static routes stuff so I'll stop brainstorming now :-)
# [09:48] * Quits: dwim (~dwim@210.94.41.89) (Quit: Leaving.)
# [09:55] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [10:11] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [10:11] * Joins: Maurice` (~copyman@unaffiliated/maurice)
# [10:13] * Quits: jdaggett_ (~jdaggett@61-121-216-2.bitcat.net) (Ping timeout: 250 seconds)
# [10:14] * Quits: KevinMarks__ (~yaaic@2607:fb90:2283:e648:464b:49f8:d286:91ad) (Ping timeout: 265 seconds)
# [10:17] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [10:18] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [10:22] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [10:23] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [10:28] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 252 seconds)
# [10:32] <JakeA> annevk: what about allowing URL.createObjectURL to take a response object? It'd need to consume the stream potentially into memory through
# [10:33] <JakeA> Hmm, going off that idea already
# [10:34] <JakeA> Maybe createCallbackURL(func), which returns a url, and when that url is loaded it calls the callback which returns a promise for a response
# [10:35] <JakeA> That callback could be _=> caches.match("/whatever")
# [10:36] <JakeA> But you could also create your own stream
# [11:04] * Quits: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Ping timeout: 244 seconds)
# [11:07] * Joins: dwim (~dwim@210.94.41.89)
# [11:09] * Joins: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [11:10] * Quits: Maurice` (~copyman@unaffiliated/maurice)
# [11:16] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-nyknkfvdzoxpjfgj)
# [11:17] * Joins: iandevlin (~iandevlin@dslb-092-072-185-159.092.072.pools.vodafone-ip.de)
# [11:18] * Quits: iandevlin (~iandevlin@dslb-092-072-185-159.092.072.pools.vodafone-ip.de) (Client Quit)
# [11:22] <annevk> JakeA: either a one-time Response -> URL mapping or supporting Response objects for all possible networking features makes a lot of sense to me
# [11:22] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [11:23] <annevk> JakeA: from past experience I'd prefer starting out with <img>.objectSrc = response over <img>.src = createURLFrom(response) given that the latter has all kinds of warts
# [11:23] <annevk> JakeA: but the latter is more portable...
# [11:25] <annevk> JakeA: and the latter could probably work fine since you just acquire a lock on the stream meaning subsequent use would fail anyway
# [11:31] <annevk> I wonder what zewt thinks about introducing URLs for Response objects with the same guarantees as blob URLs (except reuse not being possible at all). I'm kind of warming up to the idea since it would be much simpler to roll out across existing features...
# [11:41] * Quits: viduthalai1947_ (uid5404@gateway/web/irccloud.com/x-yxecuezvfvnmwscs) (Quit: Connection closed for inactivity)
# [11:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [11:50] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [12:00] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [12:00] * Quits: technommy (~tommyliu@116.25.160.250) (Remote host closed the connection)
# [12:04] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 252 seconds)
# [12:05] <annevk> Ooh exciting, it seems we can let sites control User-Agent soonish :-)
# [12:12] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [12:16] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 250 seconds)
# [12:28] * Quits: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net) (Ping timeout: 244 seconds)
# [12:30] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 264 seconds)
# [12:32] * Joins: hgl (~hgl@unaffiliated/hgl)
# [12:33] * Joins: ^esc (~esc-ape@178.115.130.145.wireless.dyn.drei.com)
# [12:35] <annevk> wanderview: JakeA: Krinkle|detached: I came up with some better terminology for this whole storage thing: https://etherpad.mozilla.org/storage
# [12:35] <annevk> wanderview: JakeA: Krinkle|detached: will likely update the wiki later
# [12:42] <JakeA> annevk: the benefit of a callback is it'd vend a new response each time, so it can be used more than once. But if that's not useful, it isn't needed
# [12:46] <annevk> JakeA: it does seem like it might be more convenient not to have to .then() to get hold of the Response...
# [12:47] <annevk> So you get code akin to <img>.src = toURL(fetch(...))
# [13:00] <annevk> The only weird thing with that is that you invoke all of Fetch twice, once for the URL inside fetch(), and once for the URL returned by toURL()...
# [13:18] * Joins: technomm_ (~tommyliu@121.15.84.11)
# [13:25] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-nhdglwyqqzkwtyhk)
# [13:25] * Quits: technomm_ (~tommyliu@121.15.84.11) (Quit: brb)
# [13:27] * Joins: tommyliu (~tommyliu@121.15.84.11)
# [13:35] <MikeSmith> would be great if somebody could post a status report of some kind for the Service Workers specーwhere things are at, what the major remaining issues are
# [13:36] <MikeSmith> the traffic on the SW issues tracker is a lot to try to keep up with, and the volume of open issues is pretty high
# [13:43] <annevk> MikeSmith: I think it's mostly just cleaning up
# [13:43] <annevk> MikeSmith: we don't have specification blockers for implementing anyway
# [13:45] <MikeSmith> annevk: ok
# [13:46] <MikeSmith> I'd volunteer to try to write something up myself based on what I've managed to keep up with from the discussions but I don't reckon I'd do a great job of it
# [13:46] * Quits: tommyliu (~tommyliu@121.15.84.11) (Remote host closed the connection)
# [13:47] <MikeSmith> in other news https://github.com/whatwg/fetch/issues/27 is epic
# [13:48] <MikeSmith> and I wonder how long that guy will keep on at https://github.com/whatwg/fetch/issues/28
# [13:48] <annevk> MikeSmith: so yeah, if you count fetch() as part of service workers I'd mention that as something we need to address
# [13:49] <annevk> MikeSmith: but I still think that can be additive, and JakeA and Domenic seem to agree
# [13:49] <MikeSmith> annevk: well it seems like the dependency should count
# [13:49] <MikeSmith> ok
# [13:51] <MikeSmith> on another meta-note I wonder how many people are paying attention to the discussions
# [13:52] <MikeSmith> looking at https://github.com/whatwg/fetch/issues/27 I see in all that traffic over the last week or whatever it's been, there's just 14 people who have commented
# [13:52] <MikeSmith> or maybe that's relatively a lot of commentors, I dunno
# [13:53] <MikeSmith> but even then there's only 32 people watching the fetch repo and reckon quite a few of the people watching don't actually read a lot of the messages
# [13:56] <MikeSmith> anyway, that's sorta why I suggested some occasional summaries would be nice to haveーto give others a heads-up about what's being discussed and why they should care
# [13:57] * Joins: scor (scor@nat/acquia/x-hsqfvegznvykrtif)
# [13:57] * Quits: scor (scor@nat/acquia/x-hsqfvegznvykrtif) (Changing host)
# [13:57] * Joins: scor (scor@drupal.org/user/52142/view)
# [14:01] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [14:04] * Joins: newtron (~newtron@206-248-160-177.dsl.teksavvy.com)
# [14:05] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 250 seconds)
# [14:06] * Joins: xiinotulp (~plutoniix@node-j0h.pool-101-108.dynamic.totbb.net)
# [14:10] * Quits: plutoniix (~plutoniix@node-ys7.pool-180-180.dynamic.totbb.net) (Ping timeout: 272 seconds)
# [14:15] * Quits: vigilvindex (~quassel@envoycorps.info) (Remote host closed the connection)
# [14:16] * Joins: vigilvindex (~quassel@envoycorps.info)
# [14:19] * Joins: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de)
# [14:30] * xiinotulp is now known as plutoniix
# [14:32] <annevk> MikeSmith: there's not a lot of signal in that thread
# [14:32] <annevk> MikeSmith: the gist is still that we don't really know how we want to do cancelation
# [14:33] <MikeSmith> annevk: OK, it's good to know that at least
# [14:33] <MikeSmith> I thought I must be missing something
# [14:34] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 250 seconds)
# [14:34] * Krinkle|detached is now known as Krinkle
# [14:35] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 256 seconds)
# [14:47] * Joins: karlcow (~karl@nerval.la-grange.net)
# [14:49] * Quits: karlcow (~karl@nerval.la-grange.net) (Client Quit)
# [14:50] * Joins: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be)
# [14:51] * Joins: zenith_ (~zenith@142.150.23.90)
# [14:56] <annevk> MikeSmith: I'm happy to help btw if anything is unclear
# [14:56] <annevk> MikeSmith: but afaict some v1 of all these features is being shipped by vendors
# [14:57] <annevk> MikeSmith: just a bit unclear how to summarize all the minutiae
# [14:58] <JakeA> annevk: MikeSmith: there's been some progress at https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e
# [14:59] <MikeSmith> annevk: occasional stuff like https://annevankesteren.nl/2015/02/cancelable-promises is nice
# [15:00] * MikeSmith looks at https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e
# [15:00] <MikeSmith> serendipity :-)
# [15:00] * Krinkle is now known as Krinkle|detached
# [15:01] <annevk> MikeSmith: that's effectively still where we are at :-)
# [15:01] <MikeSmith> JakeA: nice
# [15:02] <annevk> (at a summary level, anyway, JakeA is making progress)
# [15:02] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
# [15:02] <JakeA> MikeSmith: the bit I'm most worried about is the "gotcha" bit, but maybe Domenic can find something under the hood that makes it not a problem (I couldn't quite get my head around the spec)
# [15:02] <JakeA> Next step is to build a prototype
# [15:03] <MikeSmith> annevk: yeah https://gist.github.com/jakearchibald/9a24f3c06f06b9c06a1e seems somewhere beyond where it was at at the time you wrote that blog post
# [15:03] <MikeSmith> JakeA: you mean the resolved-but-unsettled promises part?
# [15:03] <JakeA> yeah
# [15:04] * Joins: tommyliu (~tommyliu@121.15.84.11)
# [15:06] <MikeSmith> I see Domenic didn't respond about that part yet
# [15:06] <MikeSmith> man this stuff is hairy
# [15:06] <JakeA> MikeSmith: I only made those edits a couple of days ago
# [15:06] <MikeSmith> ah ok
# [15:10] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
# [15:15] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
# [15:17] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [15:21] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 250 seconds)
# [15:24] * Quits: zenith_ (~zenith@142.150.23.90) (Ping timeout: 250 seconds)
# [15:30] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-wcmmyxxrvtytohpc)
# [15:50] * Quits: tomaw (tom@freenode/staff/tomaw) (*.net *.split)
# [15:50] * Quits: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de) (*.net *.split)
# [15:50] * Quits: halfline (rstrode@nat/redhat/x-onbkhhnomelhgevj) (*.net *.split)
# [15:50] * Quits: vigilvindex (~quassel@envoycorps.info) (*.net *.split)
# [15:50] * Quits: rcombs (~rcombs@rcombs.me) (*.net *.split)
# [15:50] * Quits: dustinm` (~dustinm@105.ip-167-114-152.net) (*.net *.split)
# [15:50] * Quits: gavinc (~gavin@4df8-a168-e2af-74d7-030d-4002-3420-2062.6rd.ip6.sonic.net) (*.net *.split)
# [15:50] * Quits: emerson (~emerson@unaffiliated/emerson) (*.net *.split)
# [15:50] * Quits: roqo (~roqo@unaffiliated/roqo) (*.net *.split)
# [15:50] * Quits: plutoniix (~plutoniix@node-j0h.pool-101-108.dynamic.totbb.net) (*.net *.split)
# [15:50] * Quits: hober (~ted@unaffiliated/hober) (*.net *.split)
# [15:50] * Quits: Yudai_ (~Yudai@c-73-170-83-204.hsd1.ca.comcast.net) (*.net *.split)
# [15:50] * Quits: Dashiva (Dashiva@wikia/Dashiva) (*.net *.split)
# [15:50] * Quits: manu (~manu@216.252.204.51) (*.net *.split)
# [15:50] * Quits: lnr (~lnr@aim.engr.arizona.edu) (*.net *.split)
# [15:50] * Quits: wakaba (~wakaba@167.225.100.220.dy.bbexcite.jp) (*.net *.split)
# [15:50] * Quits: mmun (~mmun@107.170.142.236) (*.net *.split)
# [15:50] * Quits: Kingdutch (~kingdutch@cookiemonster.alexandervarwijk.com) (*.net *.split)
# [15:50] * Quits: wilhelm (~wilhelm@178.255.149.100) (*.net *.split)
# [15:50] * Quits: Philip`_ (~philip@compass.zaynar.co.uk) (*.net *.split)
# [15:50] * Quits: webben_ (~benjamin@hq.benjaminhawkeslewis.com) (*.net *.split)
# [15:50] * Quits: calvaris (~calvaris@fanzine.igalia.com) (*.net *.split)
# [15:50] * Quits: arv (sid4269@gateway/web/irccloud.com/x-jobczpfaxqxqjygr) (*.net *.split)
# [15:50] * Quits: iamstef (sid12605@gateway/web/irccloud.com/x-iozjblydqusrmjjq) (*.net *.split)
# [15:50] * Quits: JonathanNeal (sid5831@gateway/web/irccloud.com/x-umlrbilawxeqxtwm) (*.net *.split)
# [15:50] * Quits: parshap (sid18846@gateway/web/irccloud.com/x-qtjrafxbnoaqnudr) (*.net *.split)
# [15:50] * Quits: ato (sid16069@gateway/web/irccloud.com/x-csfyqyroxqqulajk) (*.net *.split)
# [15:50] * Quits: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2) (*.net *.split)
# [15:50] * Quits: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402) (*.net *.split)
# [15:50] * Quits: mpt (~mpt@canonical/mpt) (*.net *.split)
# [15:50] * Quits: yutak (~yutak@2401:fa00:4:1000:8153:72f3:68fa:67b0) (*.net *.split)
# [15:50] * Quits: kochi (~kochi@2401:fa00:4:1000:2dc6:66ba:37e5:df7f) (*.net *.split)
# [15:50] * Quits: moo-_- (miohtama@lakka.kapsi.fi) (*.net *.split)
# [15:50] * Quits: jxs (~joaoxsoul@media.fcsh.unl.pt) (*.net *.split)
# [15:50] * Quits: stalled (~stalled@unaffiliated/stalled) (*.net *.split)
# [15:50] * Quits: SimonSapin (~simon@hako.exyr.org) (*.net *.split)
# [15:50] * Quits: hgl (~hgl@unaffiliated/hgl) (*.net *.split)
# [15:50] * Quits: dwim (~dwim@210.94.41.89) (*.net *.split)
# [15:50] * Quits: jahman (~woops@129.175.204.73) (*.net *.split)
# [15:50] * Quits: [swift] (~swift@maya.sethfowler.org) (*.net *.split)
# [15:50] * Quits: edsu (~edsu@pdpc/supporter/active/edsu) (*.net *.split)
# [15:50] * Quits: Joseph_Silber (~JosephSil@ool-43513ca2.dyn.optonline.net) (*.net *.split)
# [15:50] * Quits: reggna (~reggna@irc.jagochmittmoln.se) (*.net *.split)
# [15:50] * Quits: rwaldron (rwaldron@gateway/shell/jquery.com/x-hxrasponqogmcbqt) (*.net *.split)
# [15:50] * Quits: bcjordan (~bcjordan@ec2-54-172-35-148.compute-1.amazonaws.com) (*.net *.split)
# [15:50] * Quits: gargamel (~cinch@ec2-54-149-248-162.us-west-2.compute.amazonaws.com) (*.net *.split)
# [15:50] * Quits: jory (~jory@supercu.be) (*.net *.split)
# [15:50] * Quits: Rubennn_ (~Rubennn@apher.gewooniets.nl) (*.net *.split)
# [15:50] * Quits: ricea (~ricea@2401:fa00:4:1000:8c82:1978:fb59:c3fb) (*.net *.split)
# [15:50] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (*.net *.split)
# [15:50] * Quits: DenSchub (~DenSchub@sprachrohr.0b101010.org) (*.net *.split)
# [15:50] * Quits: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com) (*.net *.split)
# [15:50] * Quits: dshwang (~dshwang@192.55.54.36) (*.net *.split)
# [15:50] * Quits: lilmonkey (~a@pdpc/supporter/professional/riven) (*.net *.split)
# [15:50] * Quits: clamstar (~rx-ident@162.243.230.189) (*.net *.split)
# [15:50] * Quits: zecho (~zecho@66-247-17-199.northern.mnscu.edu) (*.net *.split)
# [15:50] * Quits: MajorT (MajorT@94-225-162-2.access.telenet.be) (*.net *.split)
# [15:50] * Quits: sarri (~sari@unaffiliated/sarri) (*.net *.split)
# [15:50] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (*.net *.split)
# [15:50] * Quits: jgraham (~jgraham@web91.webfaction.com) (*.net *.split)
# [15:50] * Quits: gavin_ (~gavin@firefox/developer/gavin) (*.net *.split)
# [15:51] * Quits: daurnimator (~daurnimat@ec2-54-86-198-100.compute-1.amazonaws.com) (*.net *.split)
# [15:51] * Quits: jst (~quassel@198.199.94.175) (*.net *.split)
# [15:51] * Quits: philipj (~philipj@37.139.17.34) (*.net *.split)
# [15:51] * Quits: MikeSmith (~mike@sideshow.default.msmith.uk0.bigv.io) (*.net *.split)
# [15:51] * Quits: j_wright (~jwright@unaffiliated/j-wright/x-9145068) (*.net *.split)
# [15:51] * Quits: terinjokes (~terinjoke@wikinews/Terinjokes) (*.net *.split)
# [15:51] * Quits: ivan\ (~ivan@unaffiliated/ivan/x-000001) (*.net *.split)
# [15:51] * Quits: nephyrin (~neph@nemu.pointysoftware.net) (*.net *.split)
# [15:51] * Quits: schuki (~quassel@vali.lamercake.org) (*.net *.split)
# [15:51] * Quits: paul_irish (~paul_iris@ve.hsh6wjwx.vesrv.com) (*.net *.split)
# [15:51] * Quits: dcheng_ (dcheng@nat/google/x-vzxsuxqmtwddyvyp) (*.net *.split)
# [15:51] * Quits: xtrm0 (uid12574@gateway/web/irccloud.com/x-wcmmyxxrvtytohpc) (*.net *.split)
# [15:51] * Quits: CvP (~CvP@203.76.123.238) (*.net *.split)
# [15:51] * Quits: robogoat (~robogoat@ec2-54-152-234-197.compute-1.amazonaws.com) (*.net *.split)
# [15:51] * Quits: tav (~tav`@host86-167-17-118.range86-167.btcentralplus.com) (*.net *.split)
# [15:51] * Quits: rego (~rego@66.193.27.77.dynamic.mundo-r.com) (*.net *.split)
# [15:51] * Quits: ondras (~ondras@zarovi.cz) (*.net *.split)
# [15:51] * Quits: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be) (*.net *.split)
# [15:51] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (*.net *.split)
# [15:51] * Quits: rektide (~rektide@eldergods.com) (*.net *.split)
# [15:51] * Quits: howitdo (~howitdo@unaffiliated/howitdo) (*.net *.split)
# [15:51] * Quits: Hixie (~ianh@178.255.149.100) (*.net *.split)
# [15:51] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (*.net *.split)
# [15:51] * Quits: danielfilho (~danielfil@208.68.39.233) (*.net *.split)
# [15:51] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (*.net *.split)
# [15:51] * Quits: Guest72872 (~tiago@bl10-136-105.dsl.telepac.pt) (*.net *.split)
# [15:51] * Quits: Workshiva (~Dashiva@74.125.121.65) (*.net *.split)
# [15:51] * Quits: leviw (sid4353@gateway/web/irccloud.com/x-cpcayryifglqdfls) (*.net *.split)
# [15:51] * Quits: matijs (sid2278@gateway/web/irccloud.com/x-kvxmndbghlqwwtaf) (*.net *.split)
# [15:51] * Quits: mkwst (sid395@gateway/web/irccloud.com/x-tvpsxciiisvvwbmo) (*.net *.split)
# [15:51] * Quits: culturelabs (sid18258@gateway/web/irccloud.com/x-gntbfwoqlxguyduj) (*.net *.split)
# [15:51] * Quits: bret (sid12421@gateway/web/irccloud.com/x-rylfuarckdssjnll) (*.net *.split)
# [15:51] * Quits: Phae (sid455@gateway/web/irccloud.com/x-urehdoyhszrhcaev) (*.net *.split)
# [15:51] * Quits: birtles (sid16523@gateway/web/irccloud.com/x-wfbcldfgipoqzzlg) (*.net *.split)
# [15:51] * Quits: jevs (sid23814@gateway/web/irccloud.com/x-zkryvqtrdbqtvdbc) (*.net *.split)
# [15:51] * Quits: slightlyoff (sid1768@gateway/web/irccloud.com/x-tkfqlhbywbqqofab) (*.net *.split)
# [15:51] * Quits: Domenic (sid10976@gateway/web/irccloud.com/x-nchfgcndqsdqzdww) (*.net *.split)
# [15:51] * Quits: sspi (sid34681@gateway/web/irccloud.com/x-dtgwnjdwelyoqjzt) (*.net *.split)
# [15:51] * Quits: cwilso__ (sid10206@gateway/web/irccloud.com/x-teslvnkbzxsjbidx) (*.net *.split)
# [15:51] * Quits: elijah (sid21431@gateway/web/irccloud.com/x-rocqofhjyallfkeu) (*.net *.split)
# [15:51] * Quits: hdv (sid2376@gateway/web/irccloud.com/x-oajhuxyiddpkfrnu) (*.net *.split)
# [15:51] * Quits: dherman (sid7996@gateway/web/irccloud.com/x-jyemwhmgodrdgmvs) (*.net *.split)
# [15:51] * Quits: morrita__ (uid16889@gateway/web/irccloud.com/x-dpugwzzvzyxqhquk) (*.net *.split)
# [15:51] * Quits: yhirano_ (uid40668@gateway/web/irccloud.com/x-qyqknecuwccaayjq) (*.net *.split)
# [15:51] * Quits: jochen__ (jochen@nat/google/x-eqwtcrsfdjswsxyo) (*.net *.split)
# [15:51] * Quits: hayato (sid20728@gateway/web/irccloud.com/x-wmlodiabokgplgqy) (*.net *.split)
# [15:51] * Quits: suzak (~suzak@www4346uf.sakura.ne.jp) (*.net *.split)
# [15:51] * Quits: Areks (~Areks@rs.gridnine.com) (*.net *.split)
# [15:51] * Quits: astearns (sid15080@gateway/web/irccloud.com/x-jqrjqbhpcwwwlmpz) (*.net *.split)
# [15:51] * Quits: tobie (sid5692@gateway/web/irccloud.com/x-ipxwinedojpgosjv) (*.net *.split)
# [15:51] * Quits: JakeA (sid3836@gateway/web/irccloud.com/x-eyiqgvpfurmbwxjr) (*.net *.split)
# [15:51] * Quits: nickstenn (~nickstenn@unaffiliated/nickstenn) (*.net *.split)
# [15:51] * Quits: globbot (~logbot@lump.glob.com.au) (*.net *.split)
# [15:51] * Quits: ryuone (~ryuone@133.242.55.223) (*.net *.split)
# [15:51] * Quits: igoroliveira (uid20755@gateway/web/irccloud.com/x-nhdglwyqqzkwtyhk) (*.net *.split)
# [15:51] * Quits: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766) (*.net *.split)
# [15:51] * Quits: falken (uid20729@gateway/web/irccloud.com/x-tzkkiacxmyzixedh) (*.net *.split)
# [15:51] * Quits: boogyman (~boogyman@pdpc/supporter/professional/boogyman) (*.net *.split)
# [15:51] * Quits: remysharp (sid4345@gateway/web/irccloud.com/x-htkrakyoltfkvkvi) (*.net *.split)
# [15:51] * Quits: abarth (sid5294@gateway/web/irccloud.com/x-pgwwpidtkiwrrypa) (*.net *.split)
# [15:51] * Quits: Rastus_Vernon (Rastus_Ver@wikimedia/Rastus-Vernon) (*.net *.split)
# [15:51] * Quits: timeless (sid4015@firefox/developer/timeless) (*.net *.split)
# [15:51] * Quits: beowulf (~sstewart@host86-153-9-85.range86-153.btcentralplus.com) (*.net *.split)
# [15:51] * Quits: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com) (*.net *.split)
# [15:51] * Quits: jyasskin_w (jyasskin@nat/google/x-rkziyehlwgqgatfh) (*.net *.split)
# [15:51] * Quits: beverloo (beverloo@nat/google/x-evgnfcezfeuubipj) (*.net *.split)
# [15:51] * Quits: dmurph (sid42525@gateway/web/irccloud.com/x-hluhszsiwptinayl) (*.net *.split)
# [15:51] * Quits: blooberry (Brian@nat/intel/x-mmmhffpzlyvslxyx) (*.net *.split)
# [15:51] * Quits: Garbee (uid21171@gateway/web/irccloud.com/x-vtnxjljlvxtalgpm) (*.net *.split)
# [15:51] * Quits: diffalot (~diffalot@unaffiliated/papyromancer) (*.net *.split)
# [15:51] * Quits: mmn (~MattN@192.95.22.58) (*.net *.split)
# [15:51] * Quits: scor (scor@drupal.org/user/52142/view) (*.net *.split)
# [15:51] * Quits: zama (~zama@unaffiliated/stryx/x-3871776) (*.net *.split)
# [15:51] * Quits: ajpiano (~ajpiano@li98-57.members.linode.com) (*.net *.split)
# [15:51] * Quits: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de) (*.net *.split)
# [15:51] * Quits: mounir (~mounir@oldworld.fr) (*.net *.split)
# [15:51] * Quits: sangwhan (~sid23@d06f3063.wiz.network) (*.net *.split)
# [15:51] * Quits: deltab (~deltab@cpc2-smal2-0-0-cust22.19-1.cable.virginm.net) (*.net *.split)
# [15:51] * Quits: payman (~payman@ip-200.t2.se.opera.com) (*.net *.split)
# [15:51] * Quits: ^esc (~esc-ape@178.115.130.145.wireless.dyn.drei.com) (*.net *.split)
# [15:51] * Quits: webguynow (~webguynow@c-73-51-235-233.hsd1.il.comcast.net) (*.net *.split)
# [15:51] * Quits: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com) (*.net *.split)
# [15:51] * Quits: dlitz (~dwon@goedel.dlitz.net) (*.net *.split)
# [15:51] * Quits: hendry (~hendry@ec2-52-74-100-218.ap-southeast-1.compute.amazonaws.com) (*.net *.split)
# [15:51] * Quits: rhiaro (~quassel@amy.so) (*.net *.split)
# [15:51] * Quits: trevnorris (~trevnorri@162.243.211.225) (*.net *.split)
# [15:51] * Quits: scott_gonzalez (gonzasi0@gateway/shell/jquery.com/x-mazomdrbztskklkb) (*.net *.split)
# [15:51] * Quits: kborchers (kborchers@gateway/shell/jquery.com/x-yfqlgsgyyeeobjex) (*.net *.split)
# [15:51] * Quits: gnarf (~gnarf@unaffiliated/gnarf) (*.net *.split)
# [15:51] * Quits: asmodai (asmodai@freebsd/developer/asmodai) (*.net *.split)
# [15:51] * Quits: Gege (gege@future.deferred.io) (*.net *.split)
# [15:51] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-nyknkfvdzoxpjfgj) (*.net *.split)
# [15:51] * Quits: roc (~chatzilla@121-99-129-246.bng1.tvc.orcon.net.nz) (*.net *.split)
# [15:51] * Quits: 6JTAAT81B (~scrollbac@gateway/web/scrollback.io/x-ezmprbpfafhspsfx) (*.net *.split)
# [15:51] * Quits: krit (sid15081@gateway/web/irccloud.com/x-ftnmtmlodsuefybk) (*.net *.split)
# [15:51] * Quits: FerasM____ (sid28672@gateway/web/irccloud.com/x-jskitiottnzvrrnv) (*.net *.split)
# [15:51] * Quits: jernoble (~jernoble@17.202.46.221) (*.net *.split)
# [15:51] * Quits: abucur (sid19072@gateway/web/irccloud.com/x-qwbfnvsghsyeziuj) (*.net *.split)
# [15:51] * Quits: sballesteros_ (sid39846@gateway/web/irccloud.com/x-korqihxdmdytuwrd) (*.net *.split)
# [15:51] * Quits: th2389_____ (sid27360@gateway/web/irccloud.com/x-unzvpvgikggnicge) (*.net *.split)
# [15:51] * Quits: miketaylr (~miketaylr@192.241.222.35) (*.net *.split)
# [15:51] * Quits: annevk (~annevk@77-57-114-240.dclient.hispeed.ch) (*.net *.split)
# [15:51] * Quits: cabanier (sid15093@gateway/web/irccloud.com/x-pnmuxmftjpyzfjdb) (*.net *.split)
# [15:51] * Quits: Johnny- (~null@unaffiliated/johnny-) (*.net *.split)
# [15:51] * Quits: biniar (~biniar@unaffiliated/biniar) (*.net *.split)
# [15:51] * Quits: jkomoros______ (sid7860@gateway/web/irccloud.com/x-qsgqnpktwbxeznhi) (*.net *.split)
# [15:51] * Quits: mrbkap (~mrbkap@63.245.214.133) (*.net *.split)
# [15:51] * Quits: gsnedders (~gsnedders@5.2.16.23) (*.net *.split)
# [15:51] * Quits: dglazkov (sid4270@gateway/web/irccloud.com/x-pmazvmelmftajumq) (*.net *.split)
# [15:51] * Quits: jtcranmer (~jcranmer@ras1.csl.tjhsst.edu) (*.net *.split)
# [15:51] * Quits: jmb (~jmb@mail.parsifal.org.uk) (*.net *.split)
# [15:51] * Quits: dfreedm (sid7859@gateway/web/irccloud.com/x-bqbzlqjtfkxyioyu) (*.net *.split)
# [15:51] * Quits: riddle (riddle@us.yunix.net) (*.net *.split)
# [15:51] * Quits: cfq (sid18398@gateway/web/irccloud.com/x-vvtshgusdtcspeyl) (*.net *.split)
# [15:51] * Quits: mathiasbynens (sid2247@gateway/web/irccloud.com/x-izjiieudmfzozrjf) (*.net *.split)
# [15:51] * Quits: jamesr___ (sid10481@gateway/web/irccloud.com/x-ijkxsezrjunqilfo) (*.net *.split)
# [15:51] * Quits: jorendorff (sid28423@gateway/web/irccloud.com/x-zgybbjedpsjywqdh) (*.net *.split)
# [15:51] * Quits: iank__ (sid43239@gateway/web/irccloud.com/x-ewqturtfvnqfpgcw) (*.net *.split)
# [15:51] * Quits: amtiskaw (sid19262@gateway/web/irccloud.com/x-dtundrmcsgyjylhz) (*.net *.split)
# [15:51] * Quits: chrisdickinson (~chrisdick@192.241.193.154) (*.net *.split)
# [15:51] * Quits: aklein (sid4454@gateway/web/irccloud.com/x-idpozxylulqzccyx) (*.net *.split)
# [15:51] * Quits: cbiesinger (sid8099@gateway/web/irccloud.com/x-lbyopkddgsuitotu) (*.net *.split)
# [15:51] * Quits: scheib (sid4467@gateway/web/irccloud.com/x-ihfsxqxckdbvldfp) (*.net *.split)
# [15:51] * Quits: frewsxcv (~frewsxcv@unaffiliated/frewsxcv) (*.net *.split)
# [15:51] * Quits: ms7821 (~Mark@rack.ms) (*.net *.split)
# [15:51] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (*.net *.split)
# [15:51] * Quits: bterlson (sid23757@gateway/web/irccloud.com/x-gprjxckcggpefvpg) (*.net *.split)
# [15:51] * Quits: tyoshino________ (sid19222@gateway/web/irccloud.com/x-kimkxxbhgxxpxrkf) (*.net *.split)
# [15:51] * Quits: mattur (sid16049@gateway/web/irccloud.com/x-bamgabcqljpgnjoy) (*.net *.split)
# [15:51] * Quits: twisted` (sid6794@gateway/web/irccloud.com/x-owcuefsxxkgmrfwt) (*.net *.split)
# [15:51] * Quits: wycats (sid79@gateway/web/irccloud.com/x-bmftcuxlzljzhvfm) (*.net *.split)
# [15:51] * Quits: ojan_ (sid5519@gateway/web/irccloud.com/x-otipcvgacmtsbdbz) (*.net *.split)
# [15:51] * Quits: TabAtkins (sid11559@gateway/web/irccloud.com/x-aikydzrluwecxufg) (*.net *.split)
# [15:51] * Quits: kirjs______ (sid25169@gateway/web/irccloud.com/x-bjgsixkyhziialcx) (*.net *.split)
# [15:51] * Quits: calvinmetcalf (sid25915@gateway/web/irccloud.com/x-ttuqdcpjhmzathzf) (*.net *.split)
# [15:51] * Quits: chee (~chee@fsf/member/chee) (*.net *.split)
# [15:51] * Quits: mvujovic (sid13458@gateway/web/irccloud.com/x-anjgmwfvthuckvez) (*.net *.split)
# [15:51] * Quits: daleharvey (sid513@gateway/web/irccloud.com/x-qxtajxbywtxuavat) (*.net *.split)
# [15:51] * Quits: wanderview (sid22777@gateway/web/irccloud.com/x-xgbnmgekncqpoijg) (*.net *.split)
# [15:51] * Quits: asabil (sid11150@gateway/web/irccloud.com/x-yyahvgtqvhugidoa) (*.net *.split)
# [15:51] * Quits: esprehn (sid10445@gateway/web/irccloud.com/x-szvtprkqnroofrbh) (*.net *.split)
# [15:51] * Quits: pdr (sid7901@gateway/web/irccloud.com/x-jegxeagwobjkysmf) (*.net *.split)
# [15:56] * Joins: ricea (~ricea@2401:fa00:4:1000:8c82:1978:fb59:c3fb)
# [15:56] * Joins: tomaw (tom@freenode/staff/tomaw)
# [15:56] * Joins: roqo (~roqo@unaffiliated/roqo)
# [15:56] * Joins: gavinc (~gavin@4df8-a168-e2af-74d7-030d-4002-3420-2062.6rd.ip6.sonic.net)
# [15:56] * Joins: rcombs (~rcombs@rcombs.me)
# [15:56] * Joins: emerson (~emerson@unaffiliated/emerson)
# [15:56] * Joins: vigilvindex (~quassel@envoycorps.info)
# [15:56] * Joins: dustinm` (~dustinm@2607:5300:100:200::160d)
# [15:56] * Joins: lnr (~lnr@aim.engr.arizona.edu)
# [15:56] * Joins: Rubennn_ (~Rubennn@apher.gewooniets.nl)
# [15:56] * Joins: jory (~jory@supercu.be)
# [15:56] * Joins: gargamel (~cinch@ec2-54-149-248-162.us-west-2.compute.amazonaws.com)
# [15:56] * Joins: bcjordan (~bcjordan@ec2-54-172-35-148.compute-1.amazonaws.com)
# [15:56] * Joins: rwaldron (rwaldron@gateway/shell/jquery.com/x-hxrasponqogmcbqt)
# [15:56] * Joins: reggna (~reggna@irc.jagochmittmoln.se)
# [15:56] * Joins: Joseph_Silber (~JosephSil@ool-43513ca2.dyn.optonline.net)
# [15:56] * Joins: edsu (~edsu@pdpc/supporter/active/edsu)
# [15:56] * Joins: [swift] (~swift@maya.sethfowler.org)
# [15:56] * Joins: jahman (~woops@129.175.204.73)
# [15:56] * Joins: dwim (~dwim@210.94.41.89)
# [15:56] * Joins: SimonSapin (~simon@hako.exyr.org)
# [15:56] * Joins: stalled (~stalled@unaffiliated/stalled)
# [15:56] * Joins: jxs (~joaoxsoul@media.fcsh.unl.pt)
# [15:56] * Joins: moo-_- (miohtama@lakka.kapsi.fi)
# [15:56] * Joins: kochi (~kochi@2401:fa00:4:1000:2dc6:66ba:37e5:df7f)
# [15:56] * Joins: yutak (~yutak@2401:fa00:4:1000:8153:72f3:68fa:67b0)
# [15:56] * Joins: mpt (~mpt@canonical/mpt)
# [15:56] * Joins: strugee (~strugee@2602:d8:a048:e600:224:8cff:fec0:402)
# [15:56] * Joins: nunnun (~hiro@2001:200:164:48:20c:29ff:fe02:11d2)
# [15:56] * Joins: ato (sid16069@gateway/web/irccloud.com/x-csfyqyroxqqulajk)
# [15:56] * Joins: parshap (sid18846@gateway/web/irccloud.com/x-qtjrafxbnoaqnudr)
# [15:56] * Joins: JonathanNeal (sid5831@gateway/web/irccloud.com/x-umlrbilawxeqxtwm)
# [15:56] * Joins: iamstef (sid12605@gateway/web/irccloud.com/x-iozjblydqusrmjjq)
# [15:56] * Joins: arv (sid4269@gateway/web/irccloud.com/x-jobczpfaxqxqjygr)
# [15:56] * Joins: calvaris (~calvaris@fanzine.igalia.com)
# [15:56] * Joins: asmodai (asmodai@freebsd/developer/asmodai)
# [15:56] * Joins: ms7821 (~Mark@rack.ms)
# [15:56] * Joins: pdr (sid7901@gateway/web/irccloud.com/x-jegxeagwobjkysmf)
# [15:56] * Joins: esprehn (sid10445@gateway/web/irccloud.com/x-szvtprkqnroofrbh)
# [15:56] * Joins: wanderview (sid22777@gateway/web/irccloud.com/x-xgbnmgekncqpoijg)
# [15:56] * Joins: gnarf (~gnarf@unaffiliated/gnarf)
# [15:56] * Joins: daleharvey (sid513@gateway/web/irccloud.com/x-qxtajxbywtxuavat)
# [15:56] * Joins: mvujovic (sid13458@gateway/web/irccloud.com/x-anjgmwfvthuckvez)
# [15:56] * Joins: chee (~chee@fsf/member/chee)
# [15:56] * Joins: kborchers (kborchers@gateway/shell/jquery.com/x-yfqlgsgyyeeobjex)
# [15:56] * Joins: sangwhan (~sid23@d06f3063.wiz.network)
# [15:56] * Joins: calvinmetcalf (sid25915@gateway/web/irccloud.com/x-ttuqdcpjhmzathzf)
# [15:56] * Joins: scheib (sid4467@gateway/web/irccloud.com/x-ihfsxqxckdbvldfp)
# [15:56] * Joins: cbiesinger (sid8099@gateway/web/irccloud.com/x-lbyopkddgsuitotu)
# [15:56] * Joins: aklein (sid4454@gateway/web/irccloud.com/x-idpozxylulqzccyx)
# [15:56] * Joins: kirjs______ (sid25169@gateway/web/irccloud.com/x-bjgsixkyhziialcx)
# [15:56] * Joins: TabAtkins (sid11559@gateway/web/irccloud.com/x-aikydzrluwecxufg)
# [15:56] * Joins: ojan_ (sid5519@gateway/web/irccloud.com/x-otipcvgacmtsbdbz)
# [15:56] * Joins: asabil (sid11150@gateway/web/irccloud.com/x-yyahvgtqvhugidoa)
# [15:56] * Joins: wycats (sid79@gateway/web/irccloud.com/x-bmftcuxlzljzhvfm)
# [15:56] * Joins: chrisdickinson (~chrisdick@192.241.193.154)
# [15:56] * Joins: scott_gonzalez (gonzasi0@gateway/shell/jquery.com/x-mazomdrbztskklkb)
# [15:56] * Joins: twisted` (sid6794@gateway/web/irccloud.com/x-owcuefsxxkgmrfwt)
# [15:56] * Joins: mattur (sid16049@gateway/web/irccloud.com/x-bamgabcqljpgnjoy)
# [15:56] * Joins: amtiskaw (sid19262@gateway/web/irccloud.com/x-dtundrmcsgyjylhz)
# [15:56] * Joins: mounir (~mounir@oldworld.fr)
# [15:56] * Joins: jorendorff (sid28423@gateway/web/irccloud.com/x-zgybbjedpsjywqdh)
# [15:56] * Joins: jamesr___ (sid10481@gateway/web/irccloud.com/x-ijkxsezrjunqilfo)
# [15:56] * Joins: tyoshino________ (sid19222@gateway/web/irccloud.com/x-kimkxxbhgxxpxrkf)
# [15:56] * Joins: mathiasbynens (sid2247@gateway/web/irccloud.com/x-izjiieudmfzozrjf)
# [15:56] * Joins: cfq (sid18398@gateway/web/irccloud.com/x-vvtshgusdtcspeyl)
# [15:56] * Joins: bterlson (sid23757@gateway/web/irccloud.com/x-gprjxckcggpefvpg)
# [15:56] * Joins: riddle (riddle@us.yunix.net)
# [15:56] * Joins: dfreedm (sid7859@gateway/web/irccloud.com/x-bqbzlqjtfkxyioyu)
# [15:56] * Joins: jmb (~jmb@mail.parsifal.org.uk)
# [15:56] * Joins: jtcranmer (~jcranmer@ras1.csl.tjhsst.edu)
# [15:56] * Joins: dglazkov (sid4270@gateway/web/irccloud.com/x-pmazvmelmftajumq)
# [15:56] * Joins: mmn (~MattN@192.95.22.58)
# [15:56] * Joins: gsnedders (~gsnedders@5.2.16.23)
# [15:56] * Joins: ryuone (~ryuone@133.242.55.223)
# [15:56] * Joins: mrbkap (~mrbkap@63.245.214.133)
# [15:56] * Joins: Gege (gege@future.deferred.io)
# [15:56] * Joins: globbot (~logbot@lump.glob.com.au)
# [15:56] * Joins: payman (~payman@ip-200.t2.se.opera.com)
# [15:56] * Joins: diffalot (~diffalot@unaffiliated/papyromancer)
# [15:56] * Joins: nickstenn (~nickstenn@unaffiliated/nickstenn)
# [15:56] * Joins: JakeA (sid3836@gateway/web/irccloud.com/x-eyiqgvpfurmbwxjr)
# [15:56] * Joins: tobie (sid5692@gateway/web/irccloud.com/x-ipxwinedojpgosjv)
# [15:56] * Joins: jkomoros______ (sid7860@gateway/web/irccloud.com/x-qsgqnpktwbxeznhi)
# [15:56] * Joins: astearns (sid15080@gateway/web/irccloud.com/x-jqrjqbhpcwwwlmpz)
# [15:56] * Joins: Areks (~Areks@rs.gridnine.com)
# [15:56] * Joins: rhiaro (~quassel@amy.so)
# [15:56] * Joins: hendry (~hendry@ec2-52-74-100-218.ap-southeast-1.compute.amazonaws.com)
# [15:56] * Joins: frewsxcv (~frewsxcv@unaffiliated/frewsxcv)
# [15:56] * Joins: ondras (~ondras@zarovi.cz)
# [15:56] * Joins: biniar (~biniar@unaffiliated/biniar)
# [15:56] * Joins: suzak (~suzak@www4346uf.sakura.ne.jp)
# [15:56] * Joins: hayato (sid20728@gateway/web/irccloud.com/x-wmlodiabokgplgqy)
# [15:56] * Joins: danielfilho (~danielfil@208.68.39.233)
# [15:56] * Joins: philipj (~philipj@37.139.17.34)
# [15:56] * Joins: MikeSmith (~mike@sideshow.default.msmith.uk0.bigv.io)
# [15:56] * Joins: j_wright (~jwright@unaffiliated/j-wright/x-9145068)
# [15:56] * Joins: terinjokes (~terinjoke@wikinews/Terinjokes)
# [15:56] * Joins: ivan\ (~ivan@unaffiliated/ivan/x-000001)
# [15:56] * Joins: nephyrin (~neph@nemu.pointysoftware.net)
# [15:56] * Joins: paul_irish (~paul_iris@ve.hsh6wjwx.vesrv.com)
# [15:56] * Joins: schuki (~quassel@vali.lamercake.org)
# [15:56] * Joins: dcheng_ (dcheng@nat/google/x-vzxsuxqmtwddyvyp)
# [15:56] * Joins: iank__ (sid43239@gateway/web/irccloud.com/x-ewqturtfvnqfpgcw)
# [15:56] * Joins: trevnorris (~trevnorri@162.243.211.225)
# [15:56] * Joins: Johnny- (~null@unaffiliated/johnny-)
# [15:56] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
# [15:56] * Joins: jst (~quassel@198.199.94.175)
# [15:56] * Joins: broquaint (~dbrook@static.94.217.47.78.clients.your-server.de)
# [15:56] * Joins: Hixie (~ianh@178.255.149.100)
# [15:56] * Joins: gavin_ (~gavin@firefox/developer/gavin)
# [15:56] * Joins: clamstar (~rx-ident@162.243.230.189)
# [15:56] * Joins: Garbee (uid21171@gateway/web/irccloud.com/x-vtnxjljlvxtalgpm)
# [15:56] * Joins: howitdo (~howitdo@unaffiliated/howitdo)
# [15:56] * Joins: lilmonkey (~a@pdpc/supporter/professional/riven)
# [15:56] * Joins: blooberry (Brian@nat/intel/x-mmmhffpzlyvslxyx)
# [15:56] * Joins: dmurph (sid42525@gateway/web/irccloud.com/x-hluhszsiwptinayl)
# [15:56] * Joins: cabanier (sid15093@gateway/web/irccloud.com/x-pnmuxmftjpyzfjdb)
# [15:56] * Joins: jochen__ (jochen@nat/google/x-eqwtcrsfdjswsxyo)
# [15:56] * Joins: jgraham (~jgraham@web91.webfaction.com)
# [15:56] * Joins: annevk (~annevk@77-57-114-240.dclient.hispeed.ch)
# [15:56] * Joins: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net)
# [15:56] * Joins: rego (~rego@66.193.27.77.dynamic.mundo-r.com)
# [15:56] * Joins: yhirano_ (uid40668@gateway/web/irccloud.com/x-qyqknecuwccaayjq)
# [15:56] * Joins: deltab (~deltab@cpc2-smal2-0-0-cust22.19-1.cable.virginm.net)
# [15:56] * Joins: beverloo (beverloo@nat/google/x-evgnfcezfeuubipj)
# [15:56] * Joins: dshwang (~dshwang@192.55.54.36)
# [15:56] * Joins: dlitz (~dwon@goedel.dlitz.net)
# [15:56] * Joins: daurnimator (~daurnimat@ec2-54-86-198-100.compute-1.amazonaws.com)
# [15:56] * Joins: jyasskin_w (jyasskin@nat/google/x-rkziyehlwgqgatfh)
# [15:56] * Joins: capella-s3 (~yaaic@cpe-24-59-162-151.twcny.res.rr.com)
# [15:56] * Joins: morrita__ (uid16889@gateway/web/irccloud.com/x-dpugwzzvzyxqhquk)
# [15:56] * Joins: beowulf (~sstewart@host86-153-9-85.range86-153.btcentralplus.com)
# [15:56] * Joins: dherman (sid7996@gateway/web/irccloud.com/x-jyemwhmgodrdgmvs)
# [15:56] * Joins: hdv (sid2376@gateway/web/irccloud.com/x-oajhuxyiddpkfrnu)
# [15:56] * Joins: timeless (sid4015@firefox/developer/timeless)
# [15:56] * Joins: miketaylr (~miketaylr@192.241.222.35)
# [15:56] * Joins: sballesteros_ (sid39846@gateway/web/irccloud.com/x-korqihxdmdytuwrd)
# [15:56] * Joins: th2389_____ (sid27360@gateway/web/irccloud.com/x-unzvpvgikggnicge)
# [15:56] * Joins: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com)
# [15:56] * Joins: elijah (sid21431@gateway/web/irccloud.com/x-rocqofhjyallfkeu)
# [15:56] * Joins: ajpiano (~ajpiano@li98-57.members.linode.com)
# [15:56] * Joins: cwilso__ (sid10206@gateway/web/irccloud.com/x-teslvnkbzxsjbidx)
# [15:56] * Joins: sspi (sid34681@gateway/web/irccloud.com/x-dtgwnjdwelyoqjzt)
# [15:56] * Joins: abucur (sid19072@gateway/web/irccloud.com/x-qwbfnvsghsyeziuj)
# [15:56] * Joins: Domenic (sid10976@gateway/web/irccloud.com/x-nchfgcndqsdqzdww)
# [15:56] * Joins: slightlyoff (sid1768@gateway/web/irccloud.com/x-tkfqlhbywbqqofab)
# [15:56] * Joins: jernoble (~jernoble@17.202.46.221)
# [15:56] * Joins: Rastus_Vernon (Rastus_Ver@wikimedia/Rastus-Vernon)
# [15:56] * Joins: rektide (~rektide@eldergods.com)
# [15:56] * Joins: zewt (~foo@ec2-50-17-220-142.compute-1.amazonaws.com)
# [15:56] * Joins: FerasM____ (sid28672@gateway/web/irccloud.com/x-jskitiottnzvrrnv)
# [15:56] * Joins: jevs (sid23814@gateway/web/irccloud.com/x-zkryvqtrdbqtvdbc)
# [15:56] * Joins: birtles (sid16523@gateway/web/irccloud.com/x-wfbcldfgipoqzzlg)
# [15:56] * Joins: Phae (sid455@gateway/web/irccloud.com/x-urehdoyhszrhcaev)
# [15:56] * Joins: bret (sid12421@gateway/web/irccloud.com/x-rylfuarckdssjnll)
# [15:56] * Joins: mkwst (sid395@gateway/web/irccloud.com/x-tvpsxciiisvvwbmo)
# [15:56] * Joins: culturelabs (sid18258@gateway/web/irccloud.com/x-gntbfwoqlxguyduj)
# [15:56] * Joins: abarth (sid5294@gateway/web/irccloud.com/x-pgwwpidtkiwrrypa)
# [15:56] * Joins: remysharp (sid4345@gateway/web/irccloud.com/x-htkrakyoltfkvkvi)
# [15:56] * Joins: matijs (sid2278@gateway/web/irccloud.com/x-kvxmndbghlqwwtaf)
# [15:56] * Joins: krit (sid15081@gateway/web/irccloud.com/x-ftnmtmlodsuefybk)
# [15:56] * Joins: leviw (sid4353@gateway/web/irccloud.com/x-cpcayryifglqdfls)
# [15:56] * Joins: Workshiva (~Dashiva@74.125.121.65)
# [15:56] * Joins: DenSchub (~DenSchub@sprachrohr.0b101010.org)
# [15:56] * Joins: webguynow (~webguynow@c-73-51-235-233.hsd1.il.comcast.net)
# [15:56] * Joins: sarri (~sari@unaffiliated/sarri)
# [15:56] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [15:56] * Joins: tav (~tav`@host86-167-17-118.range86-167.btcentralplus.com)
# [15:56] * Joins: 6JTAAT81B (~scrollbac@gateway/web/scrollback.io/x-ezmprbpfafhspsfx)
# [15:56] * Joins: boogyman (~boogyman@pdpc/supporter/professional/boogyman)
# [15:56] * Joins: MajorT (MajorT@94-225-162-2.access.telenet.be)
# [15:56] * Joins: robogoat (~robogoat@ec2-54-152-234-197.compute-1.amazonaws.com)
# [15:56] * Joins: zama (~zama@unaffiliated/stryx/x-3871776)
# [15:56] * Joins: falken (uid20729@gateway/web/irccloud.com/x-tzkkiacxmyzixedh)
# [15:56] * Joins: CvP (~CvP@203.76.123.238)
# [15:56] * Joins: c74d (~c74d3a4eb@2002:4404:712c:0:76de:2bff:fed4:2766)
# [15:56] * Joins: Guest72872 (~tiago@bl10-136-105.dsl.telepac.pt)
# [15:56] * Joins: roc (~chatzilla@121-99-129-246.bng1.tvc.orcon.net.nz)
# [15:56] * Joins: alrra (uid62345@gateway/web/irccloud.com/x-nyknkfvdzoxpjfgj)
# [15:56] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [15:56] * Joins: ^esc (~esc-ape@178.115.130.145.wireless.dyn.drei.com)
# [15:56] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-nhdglwyqqzkwtyhk)
# [15:56] * Joins: scor (scor@drupal.org/user/52142/view)
# [15:56] * Joins: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be)
# [15:56] * Joins: zecho (~zecho@66-247-17-199.northern.mnscu.edu)
# [15:56] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
# [15:56] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
# [15:56] * Joins: xtrm0 (uid12574@gateway/web/irccloud.com/x-wcmmyxxrvtytohpc)
# [15:56] * Joins: frivoal (~frivoal@cm-84.208.175.177.getinternet.no)
# [15:56] * Joins: TallTed (~Thud@63.119.36.36)
# [15:56] * Joins: plutoniix (~plutoniix@node-j0h.pool-101-108.dynamic.totbb.net)
# [15:56] * Joins: mmun (~mmun@107.170.142.236)
# [15:56] * Joins: hober (~ted@unaffiliated/hober)
# [15:56] * Joins: Yudai_ (~Yudai@c-73-170-83-204.hsd1.ca.comcast.net)
# [15:56] * Joins: Dashiva (Dashiva@wikia/Dashiva)
# [15:56] * Joins: manu (~manu@216.252.204.51)
# [15:56] * Joins: wakaba (~wakaba@167.225.100.220.dy.bbexcite.jp)
# [15:56] * Joins: Kingdutch (~kingdutch@cookiemonster.alexandervarwijk.com)
# [15:56] * Joins: wilhelm (~wilhelm@178.255.149.100)
# [15:56] * Joins: Philip`_ (~philip@compass.zaynar.co.uk)
# [15:56] * Joins: webben_ (~benjamin@hq.benjaminhawkeslewis.com)
# [15:56] * Quits: falken (uid20729@gateway/web/irccloud.com/x-tzkkiacxmyzixedh) (Ping timeout: 256 seconds)
# [15:56] * Joins: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de)
# [15:56] * Joins: halfline (rstrode@nat/redhat/x-onbkhhnomelhgevj)
# [15:56] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
# [15:57] * Joins: hgl (~hgl@unaffiliated/hgl)
# [15:57] * Joins: eBureau (~Bruno@181.164.77.172)
# [15:57] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
# [15:57] * Quits: dustinm` (~dustinm@2607:5300:100:200::160d) (*.net *.split)
# [15:57] * Quits: vigilvindex (~quassel@envoycorps.info) (*.net *.split)
# [15:57] * Quits: rcombs (~rcombs@rcombs.me) (*.net *.split)
# [15:57] * Quits: gavinc (~gavin@4df8-a168-e2af-74d7-030d-4002-3420-2062.6rd.ip6.sonic.net) (*.net *.split)
# [15:57] * Quits: emerson (~emerson@unaffiliated/emerson) (*.net *.split)
# [15:57] * Quits: roqo (~roqo@unaffiliated/roqo) (*.net *.split)
# [15:57] * Joins: rcombs (~rcombs@rcombs.me)
# [15:58] * Joins: vigilvindex (~quassel@envoycorps.info)
# [15:58] * Joins: emerson (~emerson@unaffiliated/emerson)
# [15:58] * Joins: gavinc (~gavin@4df8-a168-e2af-74d7-030d-4002-3420-2062.6rd.ip6.sonic.net)
# [15:58] * Joins: roqo (~roqo@unaffiliated/roqo)
# [15:58] * Quits: vigilvindex (~quassel@envoycorps.info) (Max SendQ exceeded)
# [15:58] * Joins: dustinm` (~dustinm@2607:5300:100:200::160d)
# [15:58] * Quits: MajorT (MajorT@94-225-162-2.access.telenet.be) (Ping timeout: 264 seconds)
# [15:59] * Joins: MajorT (MajorT@94-225-162-2.access.telenet.be)
# [15:59] * Joins: vigilvindex (~quassel@envoycorps.info)
# [15:59] <wanderview> annevk: JakeA: we would have some implementation headaches if we allow "non-standard" schemes in Cache... gecko's requirement to do full url parsing on the main thread is a major pain
# [15:59] <wanderview> I get around that by leaning on the http/https only requirement
# [15:59] * Joins: falken (uid20729@gateway/web/irccloud.com/x-bhbjmnzptosmtwny)
# [16:00] <wanderview> we only check the request url, though... so a SW could always load from some other URL scheme and then manually cache.put() it in with an http request
# [16:01] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
# [16:09] <wanderview> annevk: JakeA: it seems referring to resources in a Cache directly from static content would need something extra logic to try to fetch if not present in cache... basically what http cache does today, but it ends up in a named Cache object
# [16:15] * Joins: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
# [16:15] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Remote host closed the connection)
# [16:15] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [16:17] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [16:18] <annevk> wanderview: yeah, I think that's why I prefer URLs from Response objects and leave that use case to "static routing"
# [16:18] <annevk> wanderview: as for non-standard schemes, we could just allow for one to keep things straightforward
# [16:18] <wanderview> annevk: I guess I didn't understand the Response URL thing
# [16:19] <wanderview> oh, you mean like a URL that says "load this from a Cache"?
# [16:21] <annevk> wanderview: a URL that says read this from this Response
# [16:21] <wanderview> annevk: oh, so I still have to have js in the loop... I thought you were trying to allow the page to load from Cache without js
# [16:21] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 250 seconds)
# [16:22] <wanderview> annevk: but yea, the Response URL could be nice for non-SW stuff... I could see things like firefoxos photo gallery using that, etc
# [16:22] <wanderview> although they've implemented it all as blobs in IDB right now
# [16:23] <Ms2ger> Fun
# [16:23] <Ms2ger> importScripts says "Resolve<#resolve-a-url> each argument."
# [16:23] <Ms2ger> #resolve-a-url says "let base be the element's base URL."
# [16:24] <annevk> wanderview: yeah the without JavaScript use case is probably best done using static routes for service workers, something we never ended up specifying since we didn't know what the perf hit of service workers was going to be in the first place
# [16:26] <wanderview> annevk: it seems now that Cache is on window we don't really need the SW to run in the non-js world... maybe I don't understand what you mean by "static routes for service workers"
# [16:28] <annevk> wanderview: well unless you want to change how you load images (and you might, and for that we have the URL for Response object idea), I'm not sure that Cache available from window will help
# [16:29] <wanderview> well... images are a special case it seems
# [16:31] * Quits: encryptd_fractl (~encryptd_@23.30.224.246) (Remote host closed the connection)
# [16:37] * Quits: sarri (~sari@unaffiliated/sarri) (Ping timeout: 264 seconds)
# [16:41] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [16:43] <annevk> Ms2ger: file a bug?
# [16:43] <Ms2ger> https://www.w3.org/Bugs/Public/show_bug.cgi?id=28411
# [16:45] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Read error: Connection reset by peer)
# [16:46] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
# [16:47] <MikeSmith> annevk: gotta appreciate the humor of http://www.w3.org/mid/4q03ia5cpqt5m0q867fffniqd6ma20f7qs@hive.bjoern.hoehrmann.de
# [16:48] <MikeSmith> or at least I assume he was sorta trying to be humorous there (by not directly pointing out that you were the one he was quoting)
# [16:48] <annevk> MikeSmith: I was about to own up to my past mistake for not addressing the problem until I found sicking's reply and remembered that being the reason
# [16:49] <annevk> MikeSmith: it was kind of funny I guess, but not super helpful
# [16:49] <MikeSmith> yeah saw your reply after that
# [16:49] * Quits: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [16:49] * Joins: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com)
# [16:50] * Joins: sarri (~sari@unaffiliated/sarri)
# [16:50] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [16:51] <MikeSmith> yeah, not helpful and not sure he actually meant it to be good-naturedly funny instead of just obnoxious
# [16:52] <MikeSmith> anyway, I think I'll take a break for now from pushing my e-mail inbox boulder up the hill, and go to the sento
# [16:52] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [16:53] * Joins: espadrine_ (~tyl@dan75-7-88-166-187-54.fbx.proxad.net)
# [16:54] * Joins: zenith_ (~zenith@142.150.23.90)
# [16:55] * Joins: KevinMarks (~KevinMark@c-67-164-14-200.hsd1.ca.comcast.net)
# [16:55] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [16:56] * Joins: Maurice` (~copyman@unaffiliated/maurice)
# [17:01] <annevk> nice
# [17:11] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [17:15] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [17:16] * Joins: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net)
# [17:18] * Joins: _ritchie_ (~andrewr@pool-108-29-197-99.nycmny.fios.verizon.net)
# [17:22] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Remote host closed the connection)
# [17:34] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [17:45] * Joins: tommyliu_ (~tommyliu@li587-82.members.linode.com)
# [17:46] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Read error: Connection reset by peer)
# [17:46] * Quits: tommyliu (~tommyliu@121.15.84.11) (Read error: Connection reset by peer)
# [17:46] * Joins: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com)
# [17:47] * Joins: tommyliu (~tommyliu@121.15.84.11)
# [17:48] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [17:48] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Ping timeout: 272 seconds)
# [17:48] * Quits: Ms2ger (~Ms2ger@d54C506D6.access.telenet.be) (Ping timeout: 250 seconds)
# [17:51] * Joins: jsbell (jsbell@nat/google/x-njkzkdxehdzbjkmk)
# [17:51] * Quits: tommyliu_ (~tommyliu@li587-82.members.linode.com) (Ping timeout: 264 seconds)
# [17:52] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 248 seconds)
# [17:56] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
# [18:04] * jsbell is now known as jsbell_gardener
# [18:06] * Joins: ap (~ap@17.202.44.214)
# [18:17] * Quits: MajorT (MajorT@94-225-162-2.access.telenet.be) (Read error: Connection reset by peer)
# [18:18] * Joins: MajorT (MajorT@94-225-162-2.access.telenet.be)
# [18:28] * Quits: malcolmva (~malcolmva@c-67-180-198-144.hsd1.ca.comcast.net) (Quit: Leaving)
# [18:29] * Quits: zenith_ (~zenith@142.150.23.90) (Remote host closed the connection)
# [18:35] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [18:45] * Joins: thinkxl (~thinkxl@74-95-237-22-Houston.hfc.comcastbusiness.net)
# [18:50] * Quits: bnicholson (~bnicholso@c-24-130-60-241.hsd1.ca.comcast.net) (Quit: This computer has gone to sleep)
# [18:51] * Quits: bradleymeck (~bradleyme@rrcs-71-41-5-28.sw.biz.rr.com) (Quit: bradleymeck)
# [18:54] <wanderview> Domenic: I thought you didn't like magic in your APIs :-)
# [19:01] * Joins: encryptd_fractl (~encryptd_@23.30.224.246)
# [19:02] * Joins: bnicholson (~bnicholso@2620:101:80fc:224:bc65:7599:ff48:70)
# [19:04] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [19:08] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 256 seconds)
# [19:09] * Joins: caitp (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [19:10] * Quits: blooberry (Brian@nat/intel/x-mmmhffpzlyvslxyx) (Quit: Leaving)
# [19:16] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [19:17] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Read error: Connection reset by peer)
# [19:17] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [19:21] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [19:21] * Quits: frivoal (~frivoal@cm-84.208.175.177.getinternet.no) (Remote host closed the connection)
# [19:23] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [19:23] * Quits: hgl (~hgl@unaffiliated/hgl) (Ping timeout: 245 seconds)
# [19:24] <Domenic> wanderview: not sure what's magical here... a Request/Response can do exactly three things: be written to disk (cache), be written socket (upload), or be read from by script.
# [19:24] <Domenic> I guess now we need to figure out what the APIs are for writing to cache and uploading
# [19:24] * Joins: hgl (~hgl@unaffiliated/hgl)
# [19:25] <wanderview> Domenic: I want to understand more why we need to expose the underlying writer for fetch and cache... I mean, are there reasons beyond progress?
# [19:26] <Domenic> wanderview: did you see my reply?
# [19:26] <wanderview> Domenic: I'm also curious if browsers today report progress for "bytes actually written on tcp connection"...
# [19:26] * Joins: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com)
# [19:28] <wanderview> Domenic: implementing that requires a lot more IPC traffic vs just "progress based on stuff read from the buffer"
# [19:28] <Domenic> wanderview: maybe I'm too Node-influenced... but there, write(chunk, cb) will only call cb when the OS has accepted the chunk
# [19:28] <Domenic> that's important for program guarantees
# [19:29] <Domenic> E.g. where you need to re-try from if there's a failure
# [19:29] * Quits: trevnorris (~trevnorri@162.243.211.225) (Ping timeout: 264 seconds)
# [19:29] <wanderview> Domenic: I think that is harder to guarantee in multi-process architectures where networking is actually done in a separate process... it also doesn't really make any guarantee about it reaching the server
# [19:29] <Domenic> or if you're sending important messages to a server, it helps you maintain invariants
# [19:29] <terinjokes> Domenic: well, that still doesn't give complete guarantees that the receiving end got it
# [19:29] * Joins: trevnorris (~trevnorri@162.243.211.225)
# [19:29] <Domenic> sure
# [19:30] <Domenic> just helps
# [19:30] <Domenic> e.g. you would base your UI off of it, but you would still validate on the server
# [19:30] <wanderview> Domenic: I guess I'm curious what we do today... I would be surprised if gecko provided this kind of progress now... no idea what chrome does
# [19:31] <Domenic> wanderview: yeah, maybe we just say that this is not information we think is important to expose to web platform authors?
# [19:31] * Quits: dbaron (~dbaron@70-36-140-197.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
# [19:31] <Domenic> i mean, not doing it today isn't necessarily an argument against it. but on the other hand i haven't heard people agitating for it.
# [19:31] * Quits: trevnorris (~trevnorri@162.243.211.225) (Client Quit)
# [19:31] * Quits: newtron (~newtron@206-248-160-177.dsl.teksavvy.com) (Remote host closed the connection)
# [19:32] <wanderview> Domenic: I've asked in our network channel... no responses yet
# [19:32] * Quits: gargamel (~cinch@ec2-54-149-248-162.us-west-2.compute.amazonaws.com) (K-Lined)
# [19:32] * Joins: trevnorris (~trevnorri@162.243.211.225)
# [19:33] <Domenic> Fetch/XHR spec is a bit ambiguous... it says "Whenever one or more bytes are transmitted" ... do a bunch of steps then eventually fire a progress event
# [19:34] * Joins: Ms2ger (~Ms2ger@193.190.253.150)
# [19:34] <Domenic> Not sure if "transmitted" here means "transmitted to the OS" or...
# [19:34] <caitp-> probably read from socket or sent to socket
# [19:34] <caitp-> no, sent to socket wouldn't make sense for upload progress
# [19:35] * wanderview is annoyed we have two XHR classes.
# [19:36] <Domenic> Gecko does?
# [19:36] <wanderview> Domenic: yea, one for main thread and one for workers
# [19:36] <Domenic> Good times.
# [19:37] <wanderview> Domenic: does XHR provide upload progress? the code I am looking at mainly seems to do download progress
# [19:38] <wanderview> oh, nm
# [19:38] <wanderview> sorry
# [19:38] * Joins: eric_carlson (~ericc@17.202.49.252)
# [19:40] <annevk> Domenic: Fetch accepts patches
# [19:40] <wanderview> Domenic: I stand correct, gecko's XHR reports progress on bytes pushed to the kernel
# [19:40] <wanderview> corrected
# [19:42] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [19:42] <caitp-> it's hard to tell what blink's does without opening an actual text editor, too hard to follow the didSendData() / dataSent() code paths through mxr --- but it's probably sent to kernel
# [19:43] <wanderview> its still a bit lame, though, since the kernel is going to buffer all but the largest uploads anyway
# [19:44] <Domenic> yeah, but it at least gives you a guarantee the socket is still alive, I assume
# [19:44] <caitp-> but it's not really "upload progress"
# [19:45] <wanderview> its admittedly better than "bytes read in a child process in the browser", though
# [19:46] <caitp-> well I mean, from a developer pov, you probably expect upload progress to indicate the amount of data the recipient has received so far
# [19:46] <caitp-> which is harder
# [19:46] <Domenic> i dunno, maybe at first, but if you thought about that for a few seconds you'd realize it makes no real sense
# [19:47] <Domenic> or does it ... TCP has ACKs...
# [19:47] <caitp-> it doesn't make any sense
# [19:47] * Domenic plans more blog posts, this time on "byte sinks"
# [19:48] <Domenic> tangent: do TCP ACKs get exposed in syscalls at all?
# [19:49] <Domenic> not that we should try to expose those (at least not in a HTTP API), but now I'm curious
# [19:49] <wanderview> Domenic: I think trying to return a promise for every chunk written in a stream is going to be pretty heavyweight from an impl point of view... thinking about what that would mean for my Cache implementation... its not just the cost of a promise... its the promise plus IPC traffic for each chunk... and a lot of added code complexity
# [19:49] <caitp-> well like
# [19:49] <caitp-> *looks at libc code :>*
# [19:50] <wanderview> Domenic: I think you have to look at the window on the TCP stream
# [19:50] <Domenic> wanderview: that's good implementer feedback I guess... although you're already doing that for XHR?
# [19:51] <wanderview> Domenic: yes, for XHR... but not for Cache
# [19:51] <Domenic> wanderview: i see... so you wouldn't be able to signal completion of a write to the filesystem? I mean libuv definitely does this, although they do use threads instead of processes, it's true.
# [19:51] <wanderview> Domenic: on the flip side... being able to see stream progress would help let us resolve a cache.put() when headers are available, but then stream to disk in the background... stream progress could be observed to detect errors in body streaming
# [19:52] <wanderview> Domenic: today cache.put() is spec'd not to resolve its Promise until all the bytes are on disk
# [19:52] <Domenic> wanderview: honestly as a developer i'd be surprised if cache.put() fulfilled earlier
# [19:52] <wanderview> which is a bit of a wart
# [19:52] <Domenic> wanderview: I'd definitely want a promise that gets fulfilled only when hte cache successfully has had my thing put in it
# [19:53] <Domenic> wanderview: so if you think there's some value in streaming in the background, I'd do something like cache.put() -> { headersDone, allDone } (two promises)
# [19:53] * Quits: trevnorris (~trevnorri@162.243.211.225) (Quit: quit all you want)
# [19:53] <wanderview> Domenic: I think the spec is a bit confusing on this point now... it currently says you can commit to the Cache before the body is complete... but resolves when the body is complete... so some other cache.match() can get the thing you just put in before your first promise resolves... I haven't implemented any of that because it seems not quite right to me
# [19:54] <Domenic> ("there is no mechanism in Linux to wait for a TCP ACK to be received" http://stackoverflow.com/a/12528808/31910
# [19:54] <Domenic> wanderview: I see, yeah...
# [19:54] <Domenic> that'd be weird...
# [19:55] <wanderview> Domenic: so if we expose some other WritableStream interface on fetch... what does that mean for Request objects with a body buffer?
# [19:55] <Domenic> imagine writing half a stream to disk, calling cache.match to get it, then ... reading half the stream? you're now talking to yourself?
# [19:55] * Joins: trevnorris (~trevnorri@162.243.211.225)
# [19:55] <wanderview> Domenic: an optimized implementation would stream it off disk as its written to disk... but thats a bit hard I think
# [19:55] <Domenic> wanderview: not sure at all... I guess we'd build those on top? So fetch(req) does `req.body.pipeTo(getMeAWritableStreamFor(req.url))`?
# [19:56] <tyoshino________> Even TCP ack tells you only that a data has successfully delivered to the destination kernel. It's unknown whether the data has been successfully accepted by the application layer or not without involving app layer ack.
# [19:56] <Domenic> wanderview: wait I think what I just wrote is wrong
# [19:56] <caitp-> tyoshino________, that's fine I think --- but it's a moot point if you have to write your own tcp stack to figure out when you get an ACK
# [19:57] <Domenic> ok so the primitive is ... some kind of httpConnection object per request, with httpConnection.ws being something you can call .write() on.
# [19:57] <Domenic> so fetch(req) creates a httpConnection for req.url, and does req.body.pipeTo(httpConnection.writable) [changing name to avoid auto-linking in IRCcloud]
# [19:57] <wanderview> Domenic: what about a compromise where you can pass a ReadableStream to Request() as the body or provide a bodyFactory function that operates on a WritableStream... by default the WritableStream goes to a pipe... but there is a SetWriterableStream() that can be called to override this... must be set before the body is ever read
# [19:58] <Domenic> whereas cache.add(req) creates a fsWriteStream for a "file" whose name is determined by req.url etc., and calls req.body.pipeTo(fsWriteStream)
# [19:58] <Domenic> wanderview: that sounds intriguing; what is SetWritableStream? Spec-only operation, or user-exposed?
# [19:58] <tyoshino________> right. posix socket API doesnt'
# [19:59] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [19:59] <Domenic> tyoshino________: out of curiousity what APIs do we use in Chrome/Blink? POSIX socket ones, or something more sophisticated?
# [19:59] <wanderview> Domenic: user exposed so js library consumers can call it... if its never updated then the bodyFactory is triggered on first body access
# [19:59] * Quits: Ms2ger (~Ms2ger@193.190.253.150) (Ping timeout: 264 seconds)
# [19:59] <wanderview> Domenic: would be nice to provide a progress thing for fixed bodies like ArrayBuffers, though
# [20:00] <Domenic> wanderview: hmmmmm this might be something we can work out ... we say that fetch(req) calls req.setWritableStream(httpConnection.writable) or something...
# [20:00] <wanderview> Domenic: exactly, yes
# [20:00] <Domenic> wanderview: sure, can definitely do once we figure out streams
# [20:00] <tyoshino________> Domenic: For Linux, yes, read(2)
# [20:00] <Domenic> wanderview: I guess the question is then whether we want to spec out httpConnection.writable as something people can access somehow
# [20:00] <boogyman> Domenic: i would think that's something for the implementors, not something defined in the spec.
# [20:01] <Domenic> boogyman: why?
# [20:01] <tyoshino________> ah, sorry. write()
# [20:01] <wanderview> Domenic: I don't see how we can do that without tackling the promise extension for fetch or a controller object for fetch... leads us to the abortable fetch thing
# [20:01] <tyoshino________> I mean write(2)
# [20:01] <Domenic> tyoshino________: any ideas on windows or mac? :P
# [20:01] <boogyman> it may be a suggestion, but why should a spec dictate how something is implemented at that level?
# [20:02] <boogyman> s/?/.
# [20:02] <Domenic> wanderview: hmm don't see how they're related... I mean in theory it could be like a new fetchUpload API.
# [20:02] * Quits: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de) (Ping timeout: 240 seconds)
# [20:02] <Domenic> boogyman: sorry, maybe I missed what you were referring to? Are you saying we shouldn't expose a writable stream for HTTP connections?
# [20:02] <wanderview> Domenic: oh... i thought we wanted to maintain fetch() as a function... I guess we need to talk to annevk
# [20:02] <Domenic> wanderview: well I'm just going crazy here in this channel, who knows
# [20:03] <wanderview> Domenic: I can try to sketch out the setWritableStream thing in the issue... I have to head to the airport in a little bit, though
# [20:03] <Domenic> wanderview: no problem, I can do it
# [20:03] <tyoshino________> Not familiar but quick codesearch tells me that WSASend for Win, and POSIX for Mac
# [20:03] <Domenic> wanderview: but the question is where do these writable streams come from, that people (who are not UAs) pass to setWritableStream()
# [20:03] <Domenic> tyoshino________: cool, thanks ^_^
# [20:03] <wanderview> Domenic: WritableStream has a constructor, no?
# [20:04] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Quit: My computer has gone to sleep. ZZZzzz…)
# [20:04] <Domenic> wanderview: sure. But why can't you get a writable stream for HTTP uploads?
# [20:04] <Domenic> wanderview: I mean a direct one, not a pipe
# [20:04] <wanderview> Domenic: I still think we want some pipe construct as well that people could use for this
# [20:04] <boogyman> Domenic: no, i'm saying that the spec should not dictate how that stream is exposed, just that one is exposed
# [20:04] <Domenic> boogyman: oh, sure. not sure what i said that contradicts that.
# [20:04] * Joins: psy_ (~psy@103.6.159.177)
# [20:04] <wanderview> Domenic: I don't understand what a "HTTP uploads" stream would do without the rest of the network stack behind it
# [20:05] <Domenic> wanderview: why wouldn't it have the rest of the network stack behind it?
# [20:05] <boogyman> Domenic wanderview: hmmmmm this might be something we can work out ... we say that fetch(req) calls req.setWritableStream(httpConnection.writable) or something...
# [20:05] <boogyman> unless i misread
# [20:05] <wanderview> Domenic: how do you get a TCP connection without doing a fetch()?
# [20:05] <Domenic> boogyman: maybe, don't take the code too literally I guess
# [20:05] <Domenic> wanderview: ah, you wouldn't, you definitely would need some new API that gets a TCP connection
# [20:06] <Domenic> wanderview: the trick is this API can't involve Request since Request is too generic
# [20:06] <boogyman> okay, that was intended as pseudo-code. carry on.
# [20:06] <Domenic> wanderview: strawperson: fetch.upload(url, method, headers) -> Promise<WritableStream>?
# [20:06] <caitp-> does webrtc use tcp for networking?
# [20:06] <caitp-> (off-topic, just wondering)
# [20:07] * Joins: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de)
# [20:07] <Domenic> caitp-: probably UDP? video/audio is generally cited as something that doesn't need reliabiity and hates latency
# [20:07] <caitp-> stackoverflow says it can be but doesn't need to be
# [20:07] <caitp-> yeah, that's why I was wondering
# [20:07] <wanderview> Domenic: but not a Request object?
# [20:08] <Domenic> wanderview: well Request has the problem that people could put it in a cache or something instead of just writing to it, right? that's how we got started here...
# [20:09] * tyoshino________ is now known as tyoshino
# [20:09] <wanderview> Domenic: I thought one of the goals was to provide primitives like Request which could be used throughout many APIs
# [20:09] <wanderview> routing around the primitive seems a step backwards
# [20:09] <Domenic> wanderview: me too, but it sounds like Request was not primitive enough :(
# [20:10] <tyoshino> a queue with readable side and writable side?
# [20:10] <Domenic> if it can be read by anyone (cache, author code, etc.), it can't represent the primitive operation of an actual ongoing HTTP request (whose body can only be read by the UA/OS)
# [20:11] <Domenic> tyoshino: that doesn't really solve things though. Authors write into the writable side, the UA reads from the readable side, and does ... what? Magic that writes to the TCP socket?
# [20:11] <Domenic> tyoshino: I'm trying to say there should be a writable stream authors can get to that represents that TCP socket
# [20:11] * Joins: frivoal_ (~frivoal@cm-84.208.175.177.getinternet.no)
# [20:12] <caitp-> so, fetch() is being used primarily for pretty high-level operations, this isn't something that emscripten would want to use for a pretend posix socket api
# [20:12] <caitp-> why does it need to be so primitive?
# [20:12] <caitp-> authors aren't going to want to be writing libc code in js
# [20:12] <Domenic> BTW just as a general sentiment check: I am feeling positive and the last 30 minutes have gotten ideas flowing :). If I seem like I'm pushing against things I'm really just trying to explore the spaces and make sure we're doing the right thing.
# [20:12] <Domenic> caitp-: fetch was/is supposed to be a low-level primitive
# [20:13] <Domenic> caitp-: library authors will in general want control
# [20:13] <caitp-> i think library authors are generally pretty happy with what XHR gives them
# [20:13] <Domenic> O_O
# [20:13] <wanderview> Domenic: I think there is an inherent mismatch with your writer-per-active-operation goal and the operation-as-object-concept of Request... let me gist something...
# [20:13] * Joins: dbaron (~dbaron@2620:101:80fb:224:2c4b:9811:5e87:8bbc)
# [20:14] * Joins: newtron (~newtron@199.71.174.203)
# [20:14] <Domenic> wanderview: agree.
# [20:14] * Quits: frivoal_ (~frivoal@cm-84.208.175.177.getinternet.no) (Client Quit)
# [20:14] * Joins: bholley (~bholley@corp.mtv2.mozilla.com)
# [20:17] <tyoshino> hmm, the key point of the discussion is the meaning of write() completion?
# [20:18] <tyoshino> sorry. i haven't caught up with the log. I was watching only the issue.
# [20:19] * Joins: zenith_ (~zenith@user3-85-128.wireless.utoronto.ca)
# [20:19] * Joins: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com)
# [20:20] <wanderview> Domenic: something like this? https://gist.github.com/wanderview/ac6052184c62d2f165ee
# [20:20] <wanderview> maybe lose the bodyAsWriter
# [20:21] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
# [20:21] <wanderview> not sure if consumers of Request should be required to call setWriter or not
# [20:22] <boogyman> is req.body.closed a promise?
# [20:22] <wanderview> boogyman: I was thinking it was something that existed as a promise... but I could be wrong
# [20:22] <tyoshino> yes, it's a promise
# [20:23] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [20:23] <tyoshino> a getter of a promise
# [20:23] * Joins: benwerd (~benwerd@199.87.84.238)
# [20:23] * Quits: jyasskin (~jyasskin@173-228-80-34.dsl.static.fusionbroadband.com) (Ping timeout: 265 seconds)
# [20:23] <caitp-> new Request(url, { body (String | Stream | ArrayBuffer | ...) }) --- different behaviour depending on what type Body is
# [20:24] <caitp-> would make more sense to most people, tbh
# [20:24] <tyoshino> though it's gone from body now and lives only on reader
# [20:24] * Quits: zenith_ (~zenith@user3-85-128.wireless.utoronto.ca) (Remote host closed the connection)
# [20:25] <wanderview> caitp-: is that "Stream" a ReadableStream or a WritableStream?
# [20:25] <caitp-> well it has to be readable
# [20:25] <Domenic> wanderview: that looks more or less good, I have some cosmetic comments. But my question is, when fetch calls setWriter, what argument does it use?
# [20:25] <caitp-> but you probably want it to be writable too
# [20:25] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [20:25] <wanderview> caitp-: thats what I want... pass ReadableStream to constructor... but to get the progress semantics Domenic wants and XHR currently provides, we need to allow access to a consumer-specific WritableStream
# [20:26] <caitp-> I don't think that's really true
# [20:26] <wanderview> Domenic: a private implementation of WritableStream
# [20:26] <Domenic> wanderview: OK. Why is it private?
# [20:26] <Domenic> wanderview: why does only the UA get to create WritableStreams representing sockets?
# [20:26] * Quits: scor (scor@drupal.org/user/52142/view) (Quit: scor)
# [20:26] <caitp-> you don't really get progress semantics from the number of bytes you've pushed to a writable stream
# [20:27] <wanderview> Domenic: because it could be c++ and it will depend on internal implementation details that can't be spec'd?
# [20:27] <wanderview> caitp-: Domenic wants the consumer stream to not resolve the write() promises until its pushed to the kernel
# [20:27] <wanderview> caitp-: which is why a pipe primitive is not adequate here
# [20:27] <Domenic> wanderview: nah :P. its observable behavior should be interoperable. it could be C++ sure, but it could be exposed to JS if we wanted it to.
# [20:28] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 276 seconds)
# [20:28] <wanderview> Domenic: because its not safe to expose sockets on the web? or are we doing the TCP spec now? :-)
# [20:28] <Domenic> s/should be/could be specced to be/
# [20:28] <caitp-> what if --- and hear me out here --- what if pushing to a writable stream was not related to progress at all
# [20:28] <Domenic> wanderview: haha, well, http://www.w3.org/2012/sysapps/tcp-udp-sockets/, but leaving that aside
# [20:28] <wanderview> Domenic: we have one for firefoxos, too
# [20:28] <Domenic> wanderview: it's not a socket though, it's just a writable stream with HTTP semantics
# [20:28] <caitp-> what if you had some kind of, I don't know, upload event tied to actually pushing the data to the kernel
# [20:28] <caitp-> sort of like what already exists
# [20:28] <wanderview> caitp-: I would be quite happy with a progress notifier separate from the stream
# [20:28] <Domenic> wanderview: maybe the API is something like new HttpUploadStream(url, method, headers)
# [20:28] * Joins: zenith_ (~zenith@user3-85-128.wireless.utoronto.ca)
# [20:29] <Domenic> caitp-: we probably want that too. but it should be explicable in terms of the stream primitive. i.e., when you drop down to the stream level, you shouldn't lose power. we should layer things appropriately.
# [20:29] <wanderview> Domenic: what does it do if you don't attach it to a fetch() call?
# [20:29] <caitp-> what is the thing gained from explaining it in terms of the stream, other than making the stream interface more complicated?
# [20:30] <Domenic> wanderview: just waving my hands here, but you don't need to fetch() a HttpUploadStream. fetch() is explained in terms of HttpUploadStream, not the other way around.
# [20:31] <Domenic> wanderview: similar to how, say, cache.add could be explained in terms of a WritableFileStream or maybe WritableDatabaseEntryStream
# [20:32] <wanderview> Domenic: so you are talking about blowing up all the stuff coming from ServiceWorker effort and replacing it with a streams foundation, no? this seems like a huge undertaking
# [20:33] <Domenic> wanderview: it's fine if HttpUploadStream is private for now. Maybe it stays private forever. But I want us to kind of acknowledge that our mental model includes more capabilities for the UA than the script, and then question whether we expose them
# [20:33] <wanderview> and in theory these specs tried to accomodate streams being added
# [20:33] <tyoshino> operation stream is one possible solution. it can propagate written-to-kernel event.
# [20:33] <Domenic> wanderview: no, not at all! I'm saying that we're continuing to do archeology, and we have to ask at each layer whether we've gotten to the bedrock or not
# [20:34] <wanderview> Domenic: I have to admit I actually said "dear god no" when I read "WritableDatabaseEntryStream" :-)
# [20:34] <Domenic> wanderview: what we're discovering is that the SW APIs are not bedrockey---Request/Response especially, since they abstract multiple things: writing to a cache, uploading, and being able to be read from user code
# [20:34] * Joins: tndrH (~Rob@cpc2-lee211-2-0-cust413.7-1.cable.virginm.net)
# [20:34] <wanderview> Domenic: doing this kind of thing adds a lot of complexity and constrain on the implementation... I would want to see huge benefits before agreeing to that
# [20:34] <Domenic> wanderview: hmmmm but don't you want the ability to do streaming writes to IndexedDB at some point in the future?
# [20:35] <caitp-> > IndexedDB
# [20:35] <Domenic> wanderview: that makes sense, it's a reasonable argument for keeping HttpUploadStream private for now until someone clamors for it.
# [20:35] <Domenic> wanderview: although I'd be curious how much extra work/constraints it adds to wrap up the code you were going to use anyway into a writable stream.
# [20:35] <wanderview> Domenic: solve abortable fetch and promise extension first? because what you really are asking for is rich promises of future behavior... say activities or maybes tasks...
# [20:35] * wanderview ducks
# [20:36] <Domenic> wanderview: totally fair to solve those first :)
# [20:36] <Domenic> wanderview: I am reasonably happy with this mental model at least
# [20:36] <wanderview> Domenic: the problem is when the spec assumes a particular implementation that cannot be easily mapped to all vendors
# [20:36] <Domenic> wanderview: as long as we are OK with authors not getting good progress event semantics out of the pipe model that we'd start with
# [20:36] <wanderview> going to low risks making things "assuming its implemented like chrome, then its easy...", etc
# [20:37] <Domenic> wanderview: well it probably helps that I don't know too much about Chrome's implementation and make unreasonable demands of everyone :)
# [20:37] <wanderview> Domenic: and I do think we want streams to IDB... but I don't know we need an abstract "DatabaseEntry" interface to do that
# [20:37] <caitp-> what are the use cases that Fetch (the api, not the XHR backend) has to accomodate?
# [20:38] <caitp-> is there like an explicit set of requirements that have been figured out?
# [20:38] <Domenic> wanderview: haha OK (re IDB)
# [20:38] <wanderview> caitp-: probably a question for annevk
# [20:39] <caitp-> i'm curious where streams need to fit into it at all, since the only thing I can think of would be uploading something that was already cached, or downloading something and using the body stream as an upload to something else
# [20:39] * jsbell_gardener tunes into the IDB discussion...
# [20:40] <Domenic> caitp-: did you see https://github.com/domenic/streams-demo ? that's another use case that was impossible with XHR/non-streaming approaches
# [20:41] <Domenic> caitp-: https://domenic.github.io/streams-demo/ is nicer
# [20:42] <wanderview> Domenic: do you anticipate adding a pipe construct to the streams spec? by which I mean an object type that provides ReadableStream, WritableStream, and a (possibly fixed) buffer
# [20:42] <annevk> caitp-: do you agree that we need to expose streams?
# [20:42] <annevk> Domenic: I'd like to avoid fetchUpload(), that sounds rather terrible
# [20:42] <caitp-> I think it would be nice to have, buuuut
# [20:42] <Domenic> wanderview: yes, definitely. Although I'd probably call it "Identity Transform Stream"
# [20:42] <caitp-> i'm not totally convinced by the use cases
# [20:43] <wanderview> Domenic: I can't tell if you are just messing with me now :-)
# [20:43] <wanderview> but I shall not object over names :-)
# [20:43] <Domenic> wanderview: no, I'm not, I promise! We even have a prototype (which suffers from a number of issues related to nobody giving it any love in a while): https://github.com/whatwg/streams/blob/master/reference-implementation/lib/transform-stream.js
# [20:43] <caitp-> if it's not something that authors are asking for, why make an api complicated just to accomodate it?
# [20:43] <caitp-> simpler is better :>
# [20:43] <annevk> caitp-: developers have been asking for streams for ages
# [20:44] <caitp-> to accomodate what, though
# [20:44] <Domenic> caitp-: did you not see the huge twitter blow-up about devs asking for streams just two weeks ago?
# [20:44] <annevk> caitp-: we've wanted to add this to XMLHttpRequest since 2008 or so
# [20:45] <caitp-> what I'm asking is, what problem is it actually solving for them, and could that problem be solved in a nicer way
# [20:45] <wanderview> Domenic: ok... so like node's Transform
# [20:45] <annevk> caitp-: the ability to process data in chunks rather than having it all buffered or written to disk
# [20:45] <Domenic> wanderview: yes, but without the silly squash-everything-into-one-object issue
# [20:46] * Domenic shudders ... node transform streams prototypally inherit from readable stream, then copy over all the writable stream methods and private state, and then they get confused because e.g. an "error" event can come from either side...
# [20:47] * Quits: Guest72872 (~tiago@bl10-136-105.dsl.telepac.pt) (Ping timeout: 272 seconds)
# [20:48] <caitp-> annevk I'm primarily talking about the upload stream though
# [20:49] <wanderview> Domenic: I guess I worry that progress via WritableStream makes it kind of hard for people to get progress... I mean... it seems like there should be an easier way if you wouldn't have been going the WritableStream route to begin with
# [20:49] * Joins: tiago (~tiago@bl7-179-77.dsl.telepac.pt)
# [20:49] * tiago is now known as Guest5201
# [20:50] <annevk> caitp-: if you want a simple one-way channel that seems ideal
# [20:51] <wanderview> Domenic: maybe there could be a request.bodyWritten promise which is the value returned from ws.write(body).... or could we set it as the value of body.pipeTo(ws)? does that promise reflect actual written status?
# [20:51] <Domenic> wanderview: I agree we should add an easy progress API on top. Is that related to the request.bodyWritten promise?
# [20:51] * wanderview starts packing up to go to the airport.
# [20:52] <wanderview> Domenic: yea... I meant a simple promise they could resolve when the bytes from a fixed or ReadableStream body have been written to the consumer-specific WritableStream
# [20:52] <wanderview> or that WritableStream resolves and says the bytes are at the kernel, I mean
# [20:52] <Domenic> body.pipeTo(ws) ... currently that will fulfill early if ws buffers some writes ... that seems wrong though, we should fix that to fulfill only after all writes and the close complete. Or maybe it already does and I'm confused.
# [20:52] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [20:53] <wanderview> Domenic: it seems the WritableStream implementation could make that determination by setting its internal buffer to "zero" effectively?
# [20:53] <Domenic> wanderview: I don't know if that's as useful as just progress events or similar on the Request object...
# [20:53] <wanderview> or just lying
# [20:53] <wanderview> Domenic: ok
# [20:53] <Domenic> wanderview: yeah I think so.
# [20:53] * Quits: zenith_ (~zenith@user3-85-128.wireless.utoronto.ca) (Remote host closed the connection)
# [20:53] <wanderview> Domenic: ok, I'll stop pestering you with this stuff now :-) later
# [20:54] <annevk> Domenic: not sure how much wiggle room there still is, but if we need to redesign certain pieces it'd be good to raise an issue on them
# [20:54] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
# [20:57] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 244 seconds)
# [20:57] <Domenic> wanderview: no problem! this was pretty great I think. Have a good flight!
# [20:58] <Domenic> annevk: yeah... I think the setWritable idea is pretty reasonable now that I keep turning it over in my head. I tried to outline it more in the issue.
# [20:58] <tyoshino> Domenic: pipeTo() promise fulfills once the source is done and dest.ready fulfills
# [20:58] <tyoshino> currently.
# [20:58] <Domenic> tyoshino: that seems bad, hmm, we should wait for dest.closed I think
# [20:59] <Domenic> on the other hand it has the flavor of something i already thought about and put the current behavior in for a good reason... darn past-Domenic.
# [20:59] <annevk> Domenic: looks reasonable
# [20:59] <Domenic> annevk: \o/
# [21:00] <annevk> Domenic: though I also got excited by the redesign everything ideas :p
# [21:00] <Domenic> hahaha
# [21:03] <wanderview> annevk: I'm leaving... but it occurs to me... will the fetch() sanitize step play havoc with this setWriter() plan? since fetch is operating on a copy of the request?
# [21:04] <tyoshino> Domenic: Yes. It was discussed in past at https://github.com/whatwg/streams/issues/236#issue-46428456
# [21:05] <annevk> wanderview: no, the stream is carefully moved
# [21:05] <wanderview> cool
# [21:05] <wanderview> ok, nye
# [21:05] <wanderview> bye
# [21:05] <annevk> wanderview: sort of akin to Domenic's design
# [21:05] <annevk> wanderview: safe travels
# [21:06] <Domenic> annevk: wanderview should get most of the credit for that design (if you're referring to the one I just left a comment about on GitHub)
# [21:08] <Domenic> tyoshino: it seems like where we ended up in that thread was that it should wait for the write (and close?) to complete, but we forgot to implement that
# [21:09] <Domenic> tyoshino: no, wait, we did implement it. dest.close().then(resolvePipeToPromise, rejectPipeToPromise)
# [21:10] <tyoshino> ah. preventClose == false
# [21:10] <Domenic> right, I see. In the preventClose === true case our semantics are perhaps unexpected
# [21:10] <Domenic> I will open an issue
# [21:10] * Quits: wnklb (~winklebee@p4FE149D1.dip0.t-ipconnect.de)
# [21:11] * Joins: weinig (~weinig@17.245.27.34)
# [21:11] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [21:12] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [21:12] <tyoshino> Domenic: BTW, I'd like to get your comment on what I was suggesting.
# [21:12] * Quits: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com) (Quit: Leaving)
# [21:12] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 252 seconds)
# [21:13] <Domenic> tyoshino: operationstream as a solution, you mean?
# [21:13] <tyoshino> Yes
# [21:13] * Joins: caitp- (~caitp@CPE48f8b385c01c-CM84948c4c6f80.cpe.net.cable.rogers.com)
# [21:13] <tyoshino> It was basically
# [21:13] <tyoshino> sorry I was unclear
# [21:13] <tyoshino> but it's
# [21:13] <tyoshino> Request/Response has an extended ReadableStream side (possible hidden)
# [21:14] <tyoshino> fetch(), cache.put(), etc. pipes the extended ReadableStream and WritableStream (CacheWritableStream, etc.)
# [21:14] <tyoshino> CacheWritableStream (possibly hidden or public)
# [21:15] <tyoshino> The extended ReadableStream can propagate completion of consumption to the Readable side of Request/Response
# [21:15] <tyoshino> e.g. written to the kernel, that is represented by write() completion of CacheWritableStream, HttpUploadWritableStream
# [21:16] <Domenic> right ... I guess I am still cautious about conflating enqueuing into a readable stream's with writing to a writable stream, and thus indirectly to an underlying sink.
# [21:17] <Domenic> also, i can't imagine a non-awkward API for acknowledging reads
# [21:17] <tyoshino> I'm concerned, if
# [21:17] <tyoshino> We want to build longer chain
# [21:18] <tyoshino> if the idea of setWriter that is kinda propagating the sink itself to left
# [21:19] <tyoshino> is better or not
# [21:19] <Domenic> "propagating the sink itself to left"?
# [21:19] <tyoshino> Hmm. I don't know if we really want to create such a longer chain
# [21:20] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [21:20] <tyoshino> left of the chain
# [21:20] <tyoshino> a -> b -> c
# [21:21] <Domenic> still a bit confused ... let's say I have res1.body -> transform1 -> transform2 -> res2.bodyWriter (a HttpUploadStream). What are you worried about?
# [21:21] <tyoshino> setWriter is kinda collapsing Request and fetch(). right?
# [21:21] * Quits: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 276 seconds)
# [21:21] <Domenic> It's saying "this Request now represents a fetch, not a cache write or anything else", is how I think of it.
# [21:24] <tyoshino> In that chain, can res1.body know when a chunk it generated has been successfully uploaded?
# [21:24] <annevk> Does it need to be this Request or can it be that the stream is now associated with a fetch?
# [21:24] <annevk> Because it's more like we discard the Request and use its stream...
# [21:25] <Domenic> annevk: well wanderview's gist makes it so you keep using the Request object ... do you think that's unworkable?
# [21:25] <Domenic> wanderview: currently no ... pipe discards write() return values and only reacts to errors and backpressure
# [21:25] <Domenic> sorry, s/wanderview/tyoshino/
# [21:26] <tyoshino> Domenic: Right. And my understanding is the goal of that is making the promise returned by write() to represent commit to file, DB, network, etc.?
# [21:26] <Domenic> tyoshino: yeah
# [21:26] <annevk> Domenic: not sure
# [21:27] <annevk> Domenic: see step 2 of https://fetch.spec.whatwg.org/#dom-global-fetch
# [21:27] <Domenic> annevk: hmm I see
# [21:28] * Quits: roc (~chatzilla@121-99-129-246.bng1.tvc.orcon.net.nz) (Remote host closed the connection)
# [21:28] <Domenic> annevk: I would imagine it could be made to work. But the question is, what do we want developers to be doing. We could also do const upload = fetch(request); upload.bodyWriter.write() with a promise subclass, I guess.
# [21:28] <tyoshino> OK. So, we can know at each point of the chain that the right half of the chain has finished consumption via write() promise
# [21:29] <Domenic> tyoshino: we could, yeah, although we currently don't, hmm.
# [21:29] <Domenic> tyoshino: the complicating factor here is that we generally anticipate some queues being introduced in each intermediate step
# [21:29] <tyoshino> i'm basically trying investigate if this appraoch works well with BYOB streaming
# [21:30] <Domenic> Ah, good question
# [21:30] <annevk> Domenic: I think for developers the easiest would be to pass a writable to Request or fetch() and have that just work
# [21:30] <tyoshino> maybe i'm too pessimistic
# [21:30] <annevk> Domenic: regardless of who reads
# [21:30] <tyoshino> but to make sure...
# [21:31] <Domenic> annevk: how do they create the writable? they can't create HttpUploadStreams...
# [21:31] <tyoshino> maybe in general transformation consumes data and generate something new to the left
# [21:31] <tyoshino> s/left/right/
# [21:32] <annevk> Domenic: body: ws => ... or some such?
# [21:32] <annevk> Domenic: the moment you start the operation the callback gets invoked and hands you a writeable
# [21:32] <Domenic> annevk: right, that was where we started, but wanderview didn't like it :)
# [21:33] <tyoshino> so, for most of transform, whether transformX has consumed the ArrayBufferView passed to transformX is meaningful
# [21:33] <annevk> Domenic: this would either be for req = new Req(..., body ...); req.body.getReader(); or when you pass to fetch(), or when you pass to cache
# [21:33] <tyoshino> transformX -> transformY
# [21:33] <annevk> Domenic: I see
# [21:33] <Domenic> tyoshino: that sounds right to me.
# [21:33] <annevk> Domenic: well the alternative is to pipe it to HttpUploadStream
# [21:33] <tyoshino> ok. then, I think the concern I had only applies to a simple queue.
# [21:34] <annevk> Domenic: and maybe the UA can do magic to make the piping disappear
# [21:34] <Domenic> annevk: the main arguments against it were in response to https://github.com/yutakahirano/fetch-with-streams/issues/30#issuecomment-90151618 but yeah agreed on pipe to HttpUploadStream
# [21:35] <annevk> Domenic: thanks for the pointer, I guess I should talk to wanderview about my concerns
# [21:36] <annevk> Domenic: and maybe he can do something even cleverer
# [21:36] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
# [21:36] <tyoshino> You said we may add an identity transform to address wanderview's needs. We might need to give the identity transform ability to propagate consumption completion signal when we designing BYOB ecosystem.
# [21:36] <tyoshino> Not sure now...
# [21:36] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [21:37] <Domenic> tyoshino: that's a good test case, very interesting. Existing transform has I believe (enqueue, done, close, error) or something, although that could become promise-returning (enqueue, close, error). Maybe the done() signal is enough to say it's consumed? But, would be worth exploring more.
# [21:38] <annevk> tyoshino: are trailers high-priority? I guess we want to do them after streams?
# [21:38] <tyoshino> yeah. let's at least investigate
# [21:38] <tyoshino> annevk: yeah
# [21:38] <tyoshino> annevk: i was requested to bring it up to the standardization body
# [21:39] <tyoshino> louiscryan who's on the issue is actual gRPC developer
# [21:40] <tyoshino> I don't know exact timeframe yet. But I just thought it's better to think of interference with streams, etc. earlier.
# [21:41] <annevk> tyoshino: sgtm
# [21:41] <tyoshino> Actual spec-cing may be not so urgent
# [21:41] <annevk> tyoshino: also, any thoughts on the HTTP proxy authentication thing from https://github.com/slightlyoff/ServiceWorker/issues/533 ?
# [21:41] <annevk> tyoshino: there's a feature to prevent redirects, but HTTP proxy authentication could still require the entire upload stream to be teed
# [21:42] <annevk> tyoshino: and while we could indeed invent another server protocol to do some damage control, that hardly seems elegant
# [21:43] <tyoshino> nothing new than what i said in the comment so far. i need to learn more about difficulties you described in your comment
# [21:43] <tyoshino> yeah
# [21:44] <annevk> so basically before Fetch hits the network the request body is teed
# [21:44] <tyoshino> i'd basically like to avoid involvement by protocol layer
# [21:44] <annevk> this is done for 1) redirects 2) HTTP auth 3) HTTP proxy auth
# [21:45] <annevk> automatic HTTP auth is disabled by fetch() so 2 is not relevant, 1 can be disabled using { redirect: "error" }
# [21:45] <annevk> leaves 3 :-(
# [21:45] * Quits: weinig (~weinig@17.245.27.34) (Quit: weinig)
# [21:45] * Quits: jernoble (~jernoble@17.202.46.221) (Read error: Connection reset by peer)
# [21:46] <tyoshino> ya...
# [21:46] <annevk> if you find anyone within Chrome happy to discuss HTTP proxy auth please send them my way :-)
# [21:47] <tyoshino> ok. i'll chime someone
# [21:49] <tyoshino> going to bed. ttyl :)
# [21:49] <annevk> same here, hope you're not in Tokyo atm :p
# [21:51] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Read error: Connection reset by peer)
# [21:53] * Joins: neonstalwart (~neonstalw@50.249.154.238)
# [21:53] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [21:54] <neonstalwart> @Domenic - fyi, you may have rushed your description for https://github.com/whatwg/streams/issues/314. check preventClose: false vs preventClose: true
# [21:59] * Joins: sicking (~sicking@64.88.227.134)
# [21:59] <Domenic> neonstalwart: thanks, fixed!
# [22:02] * Joins: KevinMarks__ (~yaaic@2607:fb90:5a7:77bc:2bed:c6e9:9ea9:1e2f)
# [22:02] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
# [22:02] * Parts: neonstalwart (~neonstalw@50.249.154.238)
# [22:02] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 248 seconds)
# [22:02] * Joins: zenith_ (~zenith@142.150.23.90)
# [22:06] * Quits: sicking (~sicking@64.88.227.134) (Ping timeout: 252 seconds)
# [22:09] * Joins: rubys (~rubys@cpe-98-27-51-253.nc.res.rr.com)
# [22:15] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Quit: bradleymeck)
# [22:16] * Joins: sicking (~sicking@64.88.227.134)
# [22:19] * Quits: zdobersek (~zan@46.166.188.237) (Quit: Leaving.)
# [22:19] * Joins: jernoble (~jernoble@17.202.46.221)
# [22:21] <wanderview> annevk: yes, the fact that fetch throws away the Request was what concerned me... I think its somewhat mitigated in that you cannot reuse a drained Request
# [22:21] <wanderview> but we've been trying to avoid consumer state on the Request
# [22:22] <wanderview> annevk: Domenic: I'm ok with new Request(url, { body: ws => blah }) if there is still an option to pass a ReadableStream in the constructor... it would just have to get progress through an alternate path, which I think Domenic said he was ok with... The WritableStream approach is really only necessary if you need to know when the bytes are written to the
# [22:22] <wanderview> kernel
# [22:23] <Domenic> (or when you're working with an abstraction or library that expects data sinks to be represented as writable streams!)
# [22:23] <wanderview> yes
# [22:24] <Domenic> And yeah, I think response.addEventListener("progress", ...), if nothing else, is totally fine to build on top of streams once we know those semantics.
# [22:25] <Domenic> oh in this case it would be request though, which brings us back to the is-request-heavy-or-light question
# [22:25] <wanderview> Domenic: I think you would have to do fetch(request, {progress: handler}); not sure what annevk feels about that
# [22:27] <wanderview> which I like... because I don't want to bite off providing progress from Cache right now
# [22:28] <wanderview> Domenic: what happens if someone does var r = new Request(url, { body: ws => blah); r.body.getReader().read()?
# [22:29] <wanderview> does it invoke the body function with a pipe just in time?
# [22:29] <wanderview> on first getReader()
# [22:31] <Domenic> wanderview: my thought was the body() function is always immediately called. Then ws routes to several different possible destinations: r.body, upload, cache, ... per my code sample, which you (rightly) pointed out was not extensible.
# [22:31] <wanderview> Domenic: I think you have to wait until a consumer sets the stream... possibly stealing the body at the same time
# [22:32] <wanderview> Domenic: maybe setting the stream should be definition mark the bodyUsed flag on the Request
# [22:32] <wanderview> actually, it definitely should
# [22:33] <Domenic> sets the stream, as in, setWriter? So we are doing a synthesis of setWriter and body: ws => blah?
# [22:33] <wanderview> Domenic: I think you can't set the writer until the Request is passed to a consumer... so I don't know how to do it immediately at construction time
# [22:34] <Domenic> wanderview: agreed, i was confused and thought going back to body: ws => blah meant going back to my code sketch
# [22:34] <wanderview> Domenic: body: ws => blah is essentially a "start pushing the body" function... we don't want to push the body until it has somewhere to go
# [22:34] <Domenic> going to have to think about how to implement that then if we want getReader() to be the trigger...
# [22:35] <wanderview> Domenic: well... set the writer stream could also trigger the push immediately at that point without getReader()... the .body stream should probably be considered locked at that point
# [22:36] <wanderview> because you don't really have a ReadableStream at all
# [22:36] * Quits: zenith_ (~zenith@142.150.23.90) (Remote host closed the connection)
# [22:36] <wanderview> I only want to auto-create a pipe if someone is using the body: ws => blah form... but then someone tries to use getReader() instead of setting a writer
# [22:36] * wanderview thinks we need a better name than body: ws => blah
# [22:37] <Domenic> right, I agree setWriter is a good trigger, but unsure about how to trigger given r.body.getReader()
# [22:37] <Domenic> heh
# [22:37] * Joins: rniwa (~rniwa@17.202.48.231)
# [22:37] <Domenic> ws-revealer?
# [22:37] <wanderview> Domenic: body getter?
# [22:37] <wanderview> trigger on body getter
# [22:37] <Domenic> yeah maybe
# [22:37] <wanderview> could play havoc with dev tools, though
# [22:37] <Domenic> yeah getters with side effects seems like it would be nice to avoid if possible
# [22:38] <Domenic> getReader() seems like the right place for this, just need to make it work in the spec, but that's on me
# [22:38] * Parts: capella (~chatzilla@cpe-24-59-162-151.twcny.res.rr.com)
# [22:38] * wanderview will accept ws-revealer although he was angling for the "the blah function".
# [22:39] * Domenic the revealer function?
# [22:39] <wanderview> ws-revealer works for me
# [22:39] <Domenic> Pretty clear instance of http://domenic.me/2014/02/13/the-revealing-constructor-pattern/ is the only reason I keep saying "revealer"
# [22:40] <Domenic> Hmm I dislike how Firefox awesomebar keeps old URLs around even though they have redirects that I've visited
# [22:40] <Domenic> (should be https://blog.domenic.me/the-revealing-constructor-pattern/ )
# [22:41] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# [22:42] <wanderview> Domenic: https://bugzilla.mozilla.org/show_bug.cgi?id=922514
# [22:42] <wanderview> Domenic: but this unfortunately was marked WONTFIX https://bugzilla.mozilla.org/show_bug.cgi?id=426142
# [22:42] <Domenic> wowww it's funny to be reminded that bugzilla has bugs about the actual browser i use not just the web platform :P
# [22:43] <Domenic> oooh yeah that latter also sucks
# [22:43] * Joins: roc (~chatzilla@2001:cb0:b202:224:2677:3ff:fece:dc64)
# [22:43] <wanderview> Domenic: I guess they don't want to break muscle memory because the site moved the page
# [22:44] * Joins: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [22:44] <Domenic> right. i guess what i find annoying is when both the old and new URLs show up in the search
# [22:44] * wanderview boggles as the boarding line form 15 minutes before boarding.
# [22:45] <wanderview> Domenic: mostly i just want it to read my mind
# [22:45] <Domenic> wanderview: it basically does. it's mind-boggling how often one character is enough for it to go on. soooo much better than chrome.
# [22:46] <Domenic> I can't type "streams-demo" into my chrome location bar and get anything, despite visiting that page all the time. "streams d" gets it in Firefox.
# [22:46] * Quits: jernoble (~jernoble@17.202.46.221) (Quit: Textual IRC Client: www.textualapp.com)
# [22:46] * Quits: hasather (~hasather@cm-84.210.170.16.getinternet.no) (Ping timeout: 264 seconds)
# [22:46] <wanderview> Domenic: in the Identity Transform stream... can we make a null transform function mean "make a buffered pipe"?
# [22:46] <Domenic> wanderview: I think that's the idea, yeah.
# [22:46] <wanderview> I'm glad I finally have it trained so "streams" goes to the spec
# [22:47] * Quits: KevinMarks__ (~yaaic@2607:fb90:5a7:77bc:2bed:c6e9:9ea9:1e2f) (Ping timeout: 245 seconds)
# [22:47] <wanderview> Domenic: in the thing you linked it throws in that case right now
# [22:47] <Domenic> wanderview: yeah, as i said, suffering from a lack of love. (Although I do always fix its tests when they break!) Also unsure whether `new TransformStream()` is good or we should do `TransformStream.identity()` or something
# [22:48] * Joins: weinig (~weinig@17.244.161.85)
# [22:48] * Quits: tantek (~tantek@50-1-62-185.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
# [22:48] <wanderview> Domenic: I commented in #20
# [22:50] * Quits: MajorT (MajorT@94-225-162-2.access.telenet.be)
# [22:52] * Joins: KevinMarks__ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net)
# [22:56] * Quits: KevinMarks_ (~yaaic@c-67-164-14-200.hsd1.ca.comcast.net) (Ping timeout: 265 seconds)
# [22:57] * Quits: eBureau (~Bruno@181.164.77.172) (Quit: Textual IRC Client: www.textualapp.com)
# [22:57] * Quits: sicking (~sicking@64.88.227.134) (Ping timeout: 240 seconds)
# [23:02] * Joins: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com)
# [23:02] * Quits: TallTed (~Thud@63.119.36.36)
# [23:05] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Remote host closed the connection)
# [23:05] * Joins: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca)
# [23:06] * Joins: ericandrewlewis_ (uid32062@gateway/web/irccloud.com/x-eqaxhdxyapjgxwyl)
# [23:06] * Joins: sicking (~sicking@64.88.227.134)
# [23:09] * Quits: ehsan (~ehsan@ip-162-250-172-190.fibre.fibrestream.ca) (Ping timeout: 240 seconds)
# [23:10] * Quits: sicking (~sicking@64.88.227.134) (Read error: Connection reset by peer)
# [23:10] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 245 seconds)
# [23:12] * Joins: tantek (~tantek@184-194-80-100.pools.spcsdns.net)
# [23:12] * Joins: ap (~ap@17.114.216.168)
# [23:14] * Quits: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com) (Ping timeout: 256 seconds)
# [23:15] * Quits: tantek (~tantek@184-194-80-100.pools.spcsdns.net) (Read error: Connection reset by peer)
# [23:15] * Joins: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com)
# [23:17] * Joins: satazor (~satazor@117.195.115.89.rev.vodafone.pt)
# [23:19] * Quits: eric_carlson (~ericc@17.202.49.252) (Ping timeout: 264 seconds)
# [23:20] * Joins: jernoble (~jernoble@17.202.46.221)
# [23:26] * Quits: bradleymeck (~bradleyme@cpe-70-114-246-88.austin.res.rr.com) (Quit: bradleymeck)
# [23:26] * Quits: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com) (Ping timeout: 256 seconds)
# [23:28] * Quits: Maurice` (~copyman@unaffiliated/maurice)
# [23:28] * Joins: hswolff (~hswolff@cpe-74-72-23-108.nyc.res.rr.com)
# [23:32] * Joins: tantek (~tantek@corp-nat.p2p.sfo1.mozilla.com)
# [23:38] * Joins: satazor_ (~satazor@bl6-111-97.dsl.telepac.pt)
# [23:39] * Quits: satazor (~satazor@117.195.115.89.rev.vodafone.pt) (Ping timeout: 245 seconds)
# [23:40] * Quits: plutoniix (~plutoniix@node-j0h.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
# [23:41] * Quits: alrra (uid62345@gateway/web/irccloud.com/x-nyknkfvdzoxpjfgj) (Quit: Connection closed for inactivity)
# [23:42] * Joins: sicking (~sicking@64.88.227.134)
# [23:45] * Quits: zama (~zama@unaffiliated/stryx/x-3871776) (Ping timeout: 245 seconds)
# [23:46] * Joins: zama (~zama@unaffiliated/stryx/x-3871776)
# [23:50] * Quits: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com) (Read error: Connection reset by peer)
# [23:51] * Joins: jacobolus (~jacobolus@70-36-196-50.dsl.static.fusionbroadband.com)
# [23:52] * Quits: bholley (~bholley@corp.mtv2.mozilla.com) (Read error: Connection reset by peer)
# [23:52] * Joins: bholley_ (~bholley@corp.mtv2.mozilla.com)
# [23:57] * Joins: hasather (~hasather@cm-84.210.170.16.getinternet.no)
# Session Close: Tue Apr 07 00:00:00 2015

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