/irc-logs / freenode / #whatwg / 2015-12-14 / end

Options:

Previous day, Next day

  1. # Session Start: Mon Dec 14 00:00:00 2015
  2. # Session Ident: #whatwg
  3. # [00:03] * Joins: bblfish (~bblfish@cpc2-popl3-2-0-cust563.13-2.cable.virginm.net)
  4. # [00:12] * Quits: josemanuel (~josemanue@80.27.11.37.dynamic.jazztel.es) (Quit: Saliendo)
  5. # [00:13] * Joins: thinkxl (thinkxl@gateway/vpn/mullvad/x-tdzkfdrgtmleaccp)
  6. # [00:16] * Joins: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com)
  7. # [00:25] * Quits: iml_1 (~user@177.234.0.238) (Ping timeout: 250 seconds)
  8. # [00:31] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  9. # [00:31] * Joins: iml_ (~user@177.234.0.238)
  10. # [00:33] * Quits: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com) (Remote host closed the connection)
  11. # [00:34] * Joins: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com)
  12. # [00:35] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 250 seconds)
  13. # [00:36] * Quits: aretecode (~aretecode@104.156.228.196) (Quit: Toodaloo)
  14. # [00:38] * Quits: jdaggett (~jdaggett@ae021089.dynamic.ppp.asahi-net.or.jp) (Quit: jdaggett)
  15. # [00:41] * Quits: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com) (Remote host closed the connection)
  16. # [00:56] * Joins: xiinotulp (~q@node-1bey.pool-101-108.dynamic.totbb.net)
  17. # [00:57] * Quits: plutoniix (~q@node-1eho.pool-101-108.dynamic.totbb.net) (Read error: Connection reset by peer)
  18. # [01:00] * Quits: bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  19. # [01:07] * Joins: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net)
  20. # [01:21] * Quits: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  21. # [01:23] * xiinotulp is now known as plutoniix
  22. # [01:23] * Joins: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net)
  23. # [01:34] * Quits: bblfish (~bblfish@cpc2-popl3-2-0-cust563.13-2.cable.virginm.net) (Remote host closed the connection)
  24. # [01:41] * Joins: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com)
  25. # [01:42] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 256 seconds)
  26. # [01:42] * Quits: Hasimir (~hfenring@unaffiliated/hasimir) (Read error: Connection reset by peer)
  27. # [01:46] * Quits: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com) (Ping timeout: 240 seconds)
  28. # [01:47] * Joins: jdaggett (~jdaggett@61-121-216-2.dh-connect.net)
  29. # [01:47] * Joins: Hasimir (~hfenring@unaffiliated/hasimir)
  30. # [01:49] * Quits: thinkxl (thinkxl@gateway/vpn/mullvad/x-tdzkfdrgtmleaccp) (Ping timeout: 250 seconds)
  31. # [01:57] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  32. # [01:59] * Quits: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net) (Ping timeout: 240 seconds)
  33. # [02:00] * Quits: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  34. # [02:03] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  35. # [02:03] * Quits: plutoniix (~q@node-1bey.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
  36. # [02:13] * Joins: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net)
  37. # [02:15] * Quits: iml_ (~user@177.234.0.238) (Ping timeout: 256 seconds)
  38. # [02:16] * Quits: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  39. # [02:18] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  40. # [02:39] * Joins: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com)
  41. # [02:45] * Quits: roc (~chatzilla@2400:e780:801:224:2677:3ff:fece:dc64) (Ping timeout: 250 seconds)
  42. # [02:47] * Joins: Joseph_Silber (~JosephSil@ool-ad038489.dyn.optonline.net)
  43. # [02:50] * Quits: JosephSilber (~JosephSil@ool-ad038489.dyn.optonline.net) (Ping timeout: 250 seconds)
  44. # [03:01] * Quits: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com) (Quit: tantek)
  45. # [03:02] * Quits: darobin (~darobin@cpe-74-64-41-253.nyc.res.rr.com) (Remote host closed the connection)
  46. # [03:12] * Joins: dbaron (~dbaron@50-0-128-58.dsl.dynamic.fusionbroadband.com)
  47. # [03:25] * Joins: iml_ (~user@189.242.221.33)
  48. # [03:54] * Quits: iml_ (~user@189.242.221.33) (Read error: Connection reset by peer)
  49. # [03:54] * Joins: iml_1 (~user@189.242.221.33)
  50. # [04:07] * Joins: roc (~chatzilla@121.98.188.221)
  51. # [04:32] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  52. # [04:36] * Quits: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net) (Ping timeout: 240 seconds)
  53. # [04:42] * Joins: plutoniix (~q@ppp-124-120-47-79.revip2.asianet.co.th)
  54. # [05:34] * Quits: psy_ (~psy@43.224.156.106) (Remote host closed the connection)
  55. # [05:35] * Quits: mattur (sid16049@gateway/web/irccloud.com/x-jvjrtebxksgmukcc) (Read error: Connection reset by peer)
  56. # [05:35] * Quits: majidvp (sid96638@gateway/web/irccloud.com/x-tirxswzlxtmpsikf) (Read error: Connection reset by peer)
  57. # [05:35] * Joins: mattur (sid16049@gateway/web/irccloud.com/x-ooavwdvrdldqpmmi)
  58. # [05:35] * Joins: majidvp (sid96638@gateway/web/irccloud.com/x-okdkpabvognfsand)
  59. # [05:37] * Quits: beverloo (beverloo@nat/google/x-ajhgvcldlcqrxepj) (Ping timeout: 250 seconds)
  60. # [05:37] * Quits: johnme_ (johnme@nat/google/x-ehrhodsnviwcjljy) (Ping timeout: 250 seconds)
  61. # [05:39] * Joins: beverloo (beverloo@nat/google/x-eurqzgwtsjgkijki)
  62. # [05:39] * Joins: johnme_ (johnme@nat/google/x-klmkfeqjvmtffece)
  63. # [05:45] * Joins: rits (~richa@117.208.120.146)
  64. # [06:06] * Joins: bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net)
  65. # [06:12] * Joins: tantek (~tantek@76.21.10.183)
  66. # [06:31] * Quits: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net) (Quit: ChatZilla 0.9.92-rdmsoft [XULRunner 35.0.1/20150122214805])
  67. # [06:39] * Quits: Johnny- (~null@unaffiliated/johnny-) (Ping timeout: 260 seconds)
  68. # [06:42] * Quits: tantek (~tantek@76.21.10.183) (Quit: tantek)
  69. # [06:45] * Joins: Johnny- (~null@unaffiliated/johnny-)
  70. # [06:57] * Joins: jacobolus (~jacobolus@72.253.72.34)
  71. # [07:07] * Joins: tantek (~tantek@c-76-21-10-183.hsd1.ca.comcast.net)
  72. # [07:12] * Quits: nikkibee (~quassel@node-1w7jr9y93irfmd7s8n7wpj59d.ipv6.telus.net) (Remote host closed the connection)
  73. # [07:12] * Quits: tantek (~tantek@c-76-21-10-183.hsd1.ca.comcast.net) (Quit: tantek)
  74. # [07:41] * Joins: dexteryy (~dexteryy@202.65.212.8)
  75. # [07:42] * Quits: dexteryy (~dexteryy@202.65.212.8) (Client Quit)
  76. # [07:58] * Joins: tantek (~tantek@70.36.197.53)
  77. # [08:04] * Joins: yoav (~yoav@37.164.51.80)
  78. # [08:14] * Quits: yoav (~yoav@37.164.51.80) (Ping timeout: 272 seconds)
  79. # [08:22] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Remote host closed the connection)
  80. # [08:23] * Quits: Goplat (~goplat@reactos/developer/Goplat) (Remote host closed the connection)
  81. # [08:32] * Quits: jdaggett (~jdaggett@61-121-216-2.dh-connect.net) (Quit: jdaggett)
  82. # [08:41] * Quits: bholley (~bholley@c-73-231-198-151.hsd1.ca.comcast.net) (Quit: ZZZzzz…)
  83. # [08:42] * Quits: boogyman (~justme_j@pdpc/supporter/professional/boogyman) (Ping timeout: 250 seconds)
  84. # [08:43] * Joins: stalled (~stalled@unaffiliated/stalled)
  85. # [08:43] * Joins: boogyman (~justme_j@pdpc/supporter/professional/boogyman)
  86. # [09:08] * Quits: rits (~richa@117.208.120.146) (Ping timeout: 250 seconds)
  87. # [09:10] * Joins: calvaris (~calvaris@fanzine.igalia.com)
  88. # [09:20] * Joins: JoWie (uid93456@gateway/web/irccloud.com/x-rqsowmcpywedldme)
  89. # [09:20] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  90. # [09:22] * Joins: zcorpan (~zcorpan@90.230.218.37)
  91. # [09:24] * Quits: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  92. # [09:40] * Joins: bblfish (~bblfish@cpc2-popl3-2-0-cust563.13-2.cable.virginm.net)
  93. # [09:44] * Quits: dbaron (~dbaron@50-0-128-58.dsl.dynamic.fusionbroadband.com) (Ping timeout: 240 seconds)
  94. # [09:47] * Quits: Guest5326 (~Areks@rs.gridnine.com) (Quit: KVIrc 4.2.0 Equilibrium http://www.kvirc.net/)
  95. # [09:48] * Quits: ohaibbq (~ohaibbq@98.248.65.213) (Remote host closed the connection)
  96. # [09:53] <MikeSmith> anybody used letsencrypt yet for a cert for one of your domains?
  97. # [09:56] <ondras> yes
  98. # [09:56] <ondras> I did
  99. # [09:56] <ondras> about a week ago
  100. # [10:00] * Joins: wbe (~textual@pd95b30f4.dip0.t-ipconnect.de)
  101. # [10:02] * Joins: Areks (~Areks@83.220.238.199)
  102. # [10:09] <philipj> MikeSmith: me too, and davve
  103. # [10:12] * Joins: yoav (~yoav@2.22.226.14)
  104. # [10:16] * Joins: wilsonpage (~wilsonpag@cpc73846-dals21-2-0-cust279.20-2.cable.virginm.net)
  105. # [10:17] * Joins: hasather (~hasather@80.91.33.141)
  106. # [10:19] <MikeSmith> ondras, philipj: was the setup as easy as you'd expected? do you know roughly how long it took you?
  107. # [10:23] <philipj> MikeSmith: it was more manual than I expected, and I probably spend 4-8 hours on it in total, two evenings I think
  108. # [10:24] <philipj> well, getting the certs was pretty quick, but tweaking everything to make https://www.ssllabs.com/ssltest/ happy took more time
  109. # [10:24] <ondras> agreed
  110. # [10:24] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  111. # [10:24] <MikeSmith> ok
  112. # [10:24] <MikeSmith> that's kind of what I figured
  113. # [10:25] <ondras> getting the cert was easy, using the "certonly" feature
  114. # [10:25] <MikeSmith> ok
  115. # [10:25] <ondras> it worked OOTB using the git version
  116. # [10:25] <MikeSmith> cool
  117. # [10:25] <philipj> ondras: were you running an HTTP server on that host at the time?
  118. # [10:25] <ondras> but getting an "A" rank (just for teh lulz, probably) meant updating to apache 2.4
  119. # [10:25] <ondras> on my old debian box
  120. # [10:25] <ondras> philipj: yes, precisely
  121. # [10:25] <ondras> and updating apache 2.2 -> 2.4 was a major pita
  122. # [10:25] <philipj> I was, and thus I coulnd't use the automatic stuff, had to had some files to make my exsiting server serve the files
  123. # [10:25] <ondras> due to poor and old vhost config on that machine
  124. # [10:26] <philipj> had to *add* some files, and change the Content-Type too
  125. # [10:26] <ondras> well the "certonly" with "--webroot" worked automatically for me
  126. # [10:26] <ondras> it placed some files to webroot, used them and removed afterwards
  127. # [10:26] <ondras> I think that one empy .someletsencryptstuff dir remained there
  128. # [10:26] <ondras> I deleted that manually
  129. # [10:27] <ondras> *empty
  130. # [10:27] <philipj> oh, I didn't know about --webroot
  131. # [10:27] <ondras> MikeSmith: I also had to install some packages to satisfy dependencies, as letsencrypt was not available as a .deb package for my distro
  132. # [10:27] * Joins: yoav (~yoav@2.22.226.14)
  133. # [10:27] <ondras> MikeSmith: but just getting this thing set up and getting the cert was about half an hour of work
  134. # [10:28] <ondras> pretty easy even with my lame admin skills
  135. # [10:29] <MikeSmith> ondras: good to know. And I'm running Debian testing, so I reckon I shouldn't have a problem with getting the packages
  136. # [10:31] <MikeSmith> for the first domain I want to set up I also already have my nginx tweaks in place with my existing cert at a full A+ https://www.ssllabs.com/ssltest/analyze.html?d=sideshowbarker.net
  137. # [10:31] <MikeSmith> so I'm hoping I won't need to (re)make those changes
  138. # [10:32] <MikeSmith> current cert expires in February so I reckon switching over before then would be good
  139. # [10:32] <MikeSmith> nice holiday project
  140. # [10:37] <ondras> cool
  141. # [10:37] <ondras> shall be straightforward in your case
  142. # [10:37] <ondras> good luck :)
  143. # [10:41] * Quits: tantek (~tantek@70.36.197.53) (Quit: tantek)
  144. # [10:41] <MikeSmith> cheers
  145. # [10:42] <philipj> ondras: did have trouble with https://github.com/letsencrypt/letsencrypt/issues/1668 ?
  146. # [10:42] * Joins: adactio (~adactio@185.65.110.45)
  147. # [10:43] <ondras> philipj: no. I used "--webroot -d domain.name -w /path/to/webroot"
  148. # [10:43] <ondras> not sure if the bug applies in this setup
  149. # [10:49] * Quits: iml_1 (~user@189.242.221.33) (Quit: Leaving.)
  150. # [10:55] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Remote host closed the connection)
  151. # [11:01] * Joins: ^esc_ (~esc_@91.141.1.130.wireless.dyn.drei.com)
  152. # [11:02] <philipj> ondras: thanks, that worked, now renewing is just a one-liner :)
  153. # [11:03] <ondras> exactly :)
  154. # [11:04] * Quits: ^esc (~esc_@77.119.129.33.wireless.dyn.drei.com) (Ping timeout: 246 seconds)
  155. # [11:06] * Quits: bengo (~textual@c-98-210-158-252.hsd1.ca.comcast.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  156. # [11:14] * Joins: mosulica (~textual@assist.ro)
  157. # [11:41] * Quits: Areks (~Areks@83.220.238.199) (Remote host closed the connection)
  158. # [11:42] * Joins: Areks (~Areks@rs.gridnine.com)
  159. # [11:50] <annevk> I guess for whatwg.org we'll just wait for DreamHost to roll out Let's Encrypt...
  160. # [11:51] <annevk> Unless that doesn't happen by the summer, in which case we might have to do something one way or another
  161. # [11:52] * Joins: howdoi (uid224@gateway/web/irccloud.com/x-ixvtpigcnmglegga)
  162. # [11:52] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  163. # [11:53] * Joins: espadrine (~tyl@213.152.2.4)
  164. # [11:55] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  165. # [11:57] * Quits: plutoniix (~q@ppp-124-120-47-79.revip2.asianet.co.th) (Quit: จรลี จรลา)
  166. # [12:00] * Joins: hasather_ (~hasather@80.91.33.151)
  167. # [12:00] * Quits: hasather_ (~hasather@80.91.33.151) (Read error: Connection reset by peer)
  168. # [12:00] * Joins: hasather_ (~hasather@80.91.33.151)
  169. # [12:00] * Joins: yoav (~yoav@2.22.226.14)
  170. # [12:01] * Quits: hasather_ (~hasather@80.91.33.151) (Remote host closed the connection)
  171. # [12:02] * Joins: hasather_ (~hasather@80.91.33.141)
  172. # [12:02] * Joins: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de)
  173. # [12:03] * Quits: hasather (~hasather@80.91.33.141) (Ping timeout: 272 seconds)
  174. # [12:21] * Parts: ricea (~ricea@2401:fa00:4:1002:c5d6:d179:7998:ff23)
  175. # [12:27] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  176. # [12:29] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  177. # [12:29] * Joins: g4 (~g4@unaffiliated/gormer)
  178. # [13:10] * Quits: wilsonpage (~wilsonpag@cpc73846-dals21-2-0-cust279.20-2.cable.virginm.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  179. # [13:27] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  180. # [13:28] * Joins: yoav (~yoav@2.22.226.14)
  181. # [13:33] * Quits: yoav (~yoav@2.22.226.14) (Ping timeout: 272 seconds)
  182. # [13:34] * Joins: yoav (~yoav@2.22.226.14)
  183. # [13:39] * Quits: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr) (Excess Flood)
  184. # [13:40] * Joins: fredy (~fredy@snf-535807.vm.okeanos.grnet.gr)
  185. # [13:45] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  186. # [13:51] * Joins: yoav (~yoav@2.22.226.14)
  187. # [13:57] * Joins: Ms2ger (~Ms2ger@ptr-2hj4tblvksdoqv3ow00nxht4s.ip6.access.telenet.be)
  188. # [13:59] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  189. # [14:08] * Quits: jacobolus (~jacobolus@72.253.72.34) (Ping timeout: 240 seconds)
  190. # [14:09] * Joins: jacobolus (~jacobolus@cpe-72-130-98-178.hawaii.res.rr.com)
  191. # [14:19] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
  192. # [14:21] * Joins: plutoniix (~q@node-1bey.pool-101-108.dynamic.totbb.net)
  193. # [14:36] * Joins: encryptd_fractal (~encryptd_@63-254-58-198.ip.mcleodusa.net)
  194. # [14:36] * Quits: bblfish (~bblfish@cpc2-popl3-2-0-cust563.13-2.cable.virginm.net) (Remote host closed the connection)
  195. # [14:40] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Ping timeout: 240 seconds)
  196. # [14:42] <annevk> Domenic: JakeA: what do you think about the suggestion in https://github.com/whatwg/fetch/issues/20#issuecomment-164421065?
  197. # [14:47] * Joins: iml_ (~user@189.242.221.33)
  198. # [14:47] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
  199. # [14:48] * Quits: iml_ (~user@189.242.221.33) (Client Quit)
  200. # [14:52] * Quits: jacobolus (~jacobolus@cpe-72-130-98-178.hawaii.res.rr.com) (Ping timeout: 272 seconds)
  201. # [14:58] * Joins: TallTed (~Thud@c-98-216-254-6.hsd1.ma.comcast.net)
  202. # [14:58] <JakeA> annevk: why does that need to be an api, given it can be implemented on top of abort() really easily?
  203. # [14:58] <annevk> JakeA: I guess folks don't want to wait for abort()
  204. # [14:58] <annevk> JakeA: but yeah, you're right
  205. # [14:59] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  206. # [15:01] <JakeA> annevk: maybe we need to look for an abort solution that doesn't have as many external dependencies as cancellable promises :/
  207. # [15:01] <JakeA> Domenic: did I see you post that there'd been discussions on cancellable promises at tc39?
  208. # [15:02] <annevk> JakeA: that is an alternative, though none look attractive enough
  209. # [15:02] <annevk> JakeA: basically the API would become worse than XHR, afaict
  210. # [15:10] <Domenic> JakeA: kind of, basically still waiting on me though.
  211. # [15:10] <Domenic> annevk: I definitely don't like providing a halfway abort method
  212. # [15:10] <Domenic> annevk: I think waiting is still the right move here tbh. XHR isn't going anywhere for now.
  213. # [15:11] <Domenic> annevk: the only feasible thing I can think of is if we say that cancelation/abortion is different from timeout, and timeout is somehow actually an error condition. In which case adding a sugary { timeout: ... } option seems somewhat OK.
  214. # [15:13] <JakeA> Domenic: I still think it's better composed in that case
  215. # [15:16] <JakeA> A timeout being a time-based reaction, where aborting the request will be one part, but rejecting could be another
  216. # [15:17] * Joins: smaug____ (~chatzilla@dyxxlkyyyyyyyyyyyyyby-3.rev.dnainternet.fi)
  217. # [15:18] <annevk> Domenic: XMLHttpRequest is not exposed in service workers, but I guess the latter are still somewhat experimental
  218. # [15:18] * Quits: Ms2ger (~Ms2ger@ptr-2hj4tblvksdoqv3ow00nxht4s.ip6.access.telenet.be) (Ping timeout: 240 seconds)
  219. # [15:19] * Joins: darobin (~darobin@209.148.63.66)
  220. # [15:21] * Joins: bblfish (~bblfish@86.21.242.52)
  221. # [15:23] <Domenic> JakeA: I don't think I understand what you're saying
  222. # [15:23] <Domenic> Oh hmm I think I do now
  223. # [15:23] <JakeA> Domenic: I could create a promise that aborts a fetch then rejects
  224. # [15:24] <Domenic> yeah, makes sense
  225. # [15:24] <Domenic> But we could say that { timeout } is sugar for that
  226. # [15:24] <Domenic> instead of sugar for just aborting the fetch
  227. # [15:26] * Joins: Ms2ger (~Ms2ger@ptr-2hj4tblvksdoqv3ow00nxht4s.ip6.access.telenet.be)
  228. # [15:29] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  229. # [15:34] * Joins: rits (~richa@117.208.123.143)
  230. # [15:38] * Joins: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net)
  231. # [15:38] * Quits: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net) (Client Quit)
  232. # [15:48] * Joins: igoroliveira (uid20755@gateway/web/irccloud.com/x-spowyntngbzevltq)
  233. # [15:52] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: Textual IRC Client: www.textualapp.com)
  234. # [15:54] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
  235. # [15:55] <wanderview> JakeA: in regards to your comment here, I personally don't like streams for progress notifications https://github.com/whatwg/fetch/issues/20#issuecomment-164457161
  236. # [15:56] <wanderview> JakeA: its problematic to get the same "progress based on when bytes are written-to/read-from OS kernel" that we have today with streams that might be piped together through many layers, etc
  237. # [15:57] <wanderview> thought I would mention it here, since that issue is not really about progress
  238. # [15:58] <JakeA> Domenic: why is sugar for timeout ok, but sugar for failing on a non-success code not ok?
  239. # [15:58] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  240. # [15:59] * Joins: myakura (uid22370@gateway/web/irccloud.com/x-gffcrzopqwejzqdt)
  241. # [15:59] <JakeA> wanderview: hmm, does that apply to both uploads and downloads?
  242. # [16:00] <wanderview> JakeA: definitely applies to uploads... I'm unsure about the requirements for downloads
  243. # [16:01] <wanderview> JakeA: requiring someone to hook the stream seems very heavyweight from an API perspective as well
  244. # [16:01] <wanderview> JakeA: I'd rather just have progress events
  245. # [16:02] <annevk> ProgressPromise?
  246. # [16:02] <annevk> wanderview: is this something that can wait though?
  247. # [16:02] * Quits: mven (~textual@cpe-173-174-112-125.austin.res.rr.com) (Ping timeout: 272 seconds)
  248. # [16:02] <annevk> wanderview: seems like doing some iterations with streams first would be good before we go higher-level again
  249. # [16:02] <wanderview> annevk: I only mention it because I see people saying "streams is the primitive for progress everyone should plan on using"
  250. # [16:03] <wanderview> annevk: not if it means we have to contort the streams implementation to accomodate these weird "progress-at-the-kernel" requirements
  251. # [16:03] <annevk> wanderview: what does the browser use internally for progress events?
  252. # [16:03] <wanderview> if we can relax those requirements, then fine by me
  253. # [16:04] * Quits: hendry (~hendry@888.dabase.com) (Ping timeout: 250 seconds)
  254. # [16:04] <wanderview> annevk: for uploads it fires events based on when things write() is called on the socket
  255. # [16:04] <wanderview> annevk: not based on when it reads the data out of the upload stream
  256. # [16:04] * Joins: ehynds (~ehynds@64.206.121.41)
  257. # [16:05] <annevk> I see
  258. # [16:06] <annevk> wanderview: you don't think placing progress observers on streams makes sense at all?
  259. # [16:07] <Domenic> JakeA: it's not really OK.
  260. # [16:07] <wanderview> annevk: sure it does, but I don't think trying to make a streams progress reflect downstream operations (like writing to the kernel) makes sense...
  261. # [16:08] <wanderview> annevk: so if people are ok with it not really being at the external interface boundary, I'm fine with it
  262. # [16:11] <annevk> wanderview: I'm not sure what that means
  263. # [16:12] <annevk> wanderview: what JakeA said in that issue makes sense to me and has been our idea about "progress" for a while
  264. # [16:12] <annevk> wanderview: if that is wrong, file an issue against streams? Or maybe against fetch? Though it seems like the streams folks would have to be convinced we need something else
  265. # [16:14] <wanderview> annevk: ok... I haven't seen the issue or PR to add this stuff... so its a bit abstract still... I am just thinking back to the debates about WritableStream for Request.body with the goal of trying to get progress at the os kernel layer... I think we backed away from that... I want to make sure we don't end up there again
  266. # [16:14] * hsivonen discovers that the ISO-2022-JP decoder in the Encoding Standard can unread two bytes after reading one byte
  267. # [16:15] <hsivonen> :-(
  268. # [16:16] * Joins: hendry (~hendry@888.dabase.com)
  269. # [16:16] <annevk> hsivonen: I think you need a buffer of three or so
  270. # [16:16] <wanderview> annevk: I guess another way to state my view... I'm fine with a progress monitor on a stream as long as its monitoring the state of that stream instance and not something else in the system
  271. # [16:16] <hsivonen> annevk: why three?
  272. # [16:17] <hsivonen> I don't want to implement any actual prepending. Unreading the byte that was just read is fine, though. Just moves the pointer backwards in a way that's never out of bounds.
  273. # [16:18] * Joins: jwalden (~waldo@c-68-60-39-249.hsd1.mi.comcast.net)
  274. # [16:18] * hsivonen tries to work out what'll happen next when the two prepended bytes are processed
  275. # [16:19] <annevk> hsivonen: oh, maybe two is sufficient with the prepend rewrite, I was just going from memory and what Joshua told me at some point
  276. # [16:21] <annevk> wanderview: that makes sense
  277. # [16:21] <hsivonen> looks like I will need to work out what the possible combinations for the fields of the ISO-2022-JP decoder are at the end of the escape state :-(
  278. # [16:22] <annevk> wanderview: perhaps it's worth raising an issue on fetch-with-streams then to point out XMLHttpRequest progress events cannot be done on top of streams?
  279. # [16:28] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  280. # [16:29] * Quits: g4 (~g4@unaffiliated/gormer) (Remote host closed the connection)
  281. # [16:32] <annevk> Domenic: thank you btw for rewriting the way workers work
  282. # [16:32] <annevk> Domenic: it bugged me too, but I thought rewriting it would require changing the way MessageChannel works
  283. # [16:35] <annevk> Domenic: seems you carefully navigated around that
  284. # [16:36] <Domenic> Yeah, that was... fun :)
  285. # [16:38] * Quits: howdoi (uid224@gateway/web/irccloud.com/x-ixvtpigcnmglegga) (Quit: Connection closed for inactivity)
  286. # [16:38] * Joins: zecho (~zecho@78-247-17-199.northern.mnscu.edu)
  287. # [16:44] <annevk> Domenic: should we have some compat label for HTML issues? To indicate interop issues and make it easier to track them?
  288. # [16:44] <Domenic> annevk: what were you thinking?
  289. # [16:45] <JakeA> annevk: wanderview: streams for reading downloads makes sense to me. When I report 50% done I expect to have 50% of the resource in my possession (ignoring lies in content-length). I agree that it might not fit for uploads.
  290. # [16:46] * Joins: mven (~textual@32.97.110.56)
  291. # [16:46] <JakeA> Since its possible for my stream to be 100% consumed but none of it sent to the server. Especially as fetch does its own buffering for redirects
  292. # [16:46] <wanderview> JakeA: yea... download is less problematic than upload... I guess because download is about "read status", while upload is really about "write status"
  293. # [16:46] <annevk> Domenic: a label called "compat" e.g., for https://github.com/whatwg/html/issues/387 which I guess is an addition/proposal, but not really in the same sense
  294. # [16:47] <Domenic> Yeah I still think sent to the kernel or TCP ACKed would be ideal, but wanderview doesn't want to implement that :(
  295. # [16:47] * Joins: yoav (~yoav@2.22.226.14)
  296. # [16:47] <Domenic> annevk: seems reasonable, yeah
  297. # [16:48] <wanderview> Domenic: I don't mind implementing it (we do it today)... I just don't want a stream created before actually opening the socket to report that status
  298. # [16:48] <Domenic> wanderview: hmm I am confused, when was anyone proposing that?
  299. # [16:49] <wanderview> Domenic: back when there was the suggestion Request should provide a WritableStream
  300. # [16:49] <wanderview> not recently
  301. # [16:49] <Domenic> I don't understand. The writable stream proposal was never saying that the write() method on the writable stream should report that status before the socket is opened.
  302. # [16:51] <wanderview> Domenic: I'm saying the Request object is time disconnected from the socket write... so is not a good place to report written-to-os-kernel status... but I don't really want to replay the whole debate again
  303. # [16:52] <Domenic> wanderview: right, OK. I was thinking of the proposal where we have a separate API for establishing an upload writable stream, not accounting for Request per se.
  304. # [16:52] <Domenic> But yeah I remember the time-disconnectedness of Request being a problem.
  305. # [16:53] <wanderview> I guess I just want to make sure we know we need something other than stream progress monitor to achieve XHR upload progress events
  306. # [16:54] * Joins: thinkxl (~thinkxl@unaffiliated/thinkxl)
  307. # [16:54] <Domenic> yeah
  308. # [16:54] <Domenic> I think my current mental model is that there is a separate establishUploadWritableStream() API
  309. # [16:55] <Domenic> and fetch(request) does const ws = establishUploadWritableStream(); request.body.pipeTo(ws)
  310. # [16:55] <Domenic> just a mental model though
  311. # [16:56] * Joins: jensnockert (~jensnocke@84.219.248.21)
  312. # [16:56] * Quits: smaug____ (~chatzilla@dyxxlkyyyyyyyyyyyyyby-3.rev.dnainternet.fi) (Ping timeout: 240 seconds)
  313. # [16:59] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  314. # [17:00] <wanderview> Domenic: implementation will likely be very different from that... javascript runs in the child process while writting the upload stream to the kernel will take place in the parent process
  315. # [17:03] * Joins: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net)
  316. # [17:03] <annevk> Domenic: reportedly bz (on vacation now) has a promise implementation of toBlob somewhere in a Mozilla bug
  317. # [17:04] <annevk> Domenic: just waiting for a decision on a new name and such
  318. # [17:04] <Domenic> annevk: we should decide on a name and let blink-dev know then...
  319. # [17:04] * Quits: mosulica (~textual@assist.ro) (Quit: Textual IRC Client: www.textualapp.com)
  320. # [17:05] <annevk> I'm happy with encode/convert, but would be good to double check with bz in January
  321. # [17:06] <Domenic> HTML's use of ES ArrayBuffer vs. IDL ArrayBuffer is pretty confused still hmm what should I do
  322. # [17:06] <annevk> Domenic: structured clone biting you?
  323. # [17:06] <Domenic> I would use IDL everywhere but the spec likes to talk about "creating ArrayBuffers" which IDL doesn't really deal with
  324. # [17:06] <annevk> Domenic: oh <canvas>
  325. # [17:07] <annevk> Domenic: in theory IDL should deal with that to some extent, to make sure the object setup is correct
  326. # [17:07] <annevk> Domenic: e.g., when we say "a new promise" or "a new XMLHttpRequest object", it has all the same problems
  327. # [17:07] <Domenic> Yeah
  328. # [17:07] <Domenic> I guess I'll switch to IDL everywhere?
  329. # [17:08] <annevk> Domenic: yeah, structured cloning itself should probably move to IDL or be rewritten to some extent
  330. # [17:08] <annevk> Domenic: but just creating objects should be fine and IDL needs some language around what "new" means or "create"
  331. # [17:08] <annevk> Domenic: similar to how it has language around "throw"
  332. # [17:08] * Joins: iml_ (~user@189-210-37-107.static.axtel.net)
  333. # [17:08] <annevk> Domenic: ideally longer term it also defines loops and such
  334. # [17:09] * Quits: zcorpan (~zcorpan@90.230.218.37) (Remote host closed the connection)
  335. # [17:19] * Joins: jensnockert_ (~jensnocke@84.219.248.21)
  336. # [17:22] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 240 seconds)
  337. # [17:26] * Joins: tantek (~tantek@70-36-197-53.dsl.dynamic.fusionbroadband.com)
  338. # [17:26] * Quits: jernoble|laptop (~jernoble@104-244-25-36.PUBLIC.monkeybrains.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  339. # [17:26] <annevk> Domenic: sad that it fall upon you to define globalThis in JavaScript, but glad you did
  340. # [17:27] <Domenic> yeah glad to finally knock that out
  341. # [17:27] <annevk> Domenic: so that was the other thing I wanted to ask about, should we use "JavaScript" or "ECMAScript" throughout?
  342. # [17:27] <Domenic> annevk: the current spec has a note about that somewhere
  343. # [17:27] <annevk> Domenic: it seems IDL uses ECMAScript, most WHATWG specs, including the one named javascript, use JavaScript
  344. # [17:28] <annevk> I think even (some of) TC39 wants to use JavaScript, but Brendan mentioned some issues with Oracle iirc
  345. # [17:28] <Domenic> "The term "JavaScript" is used to refer to ECMA262, rather than the official term ECMAScript, since the term JavaScript is more widely known."
  346. # [17:28] * gsnedders waits for Oracle sue
  347. # [17:28] <Domenic> I think using JS is pretty good
  348. # [17:28] <gsnedders> annevk: there are issues with Oracle because they own the JavaScript trademark
  349. # [17:28] <annevk> Okay, I guess we should just stick to that then
  350. # [17:29] <Domenic> Hmm I won't bother updating this "lives in a window"/"lives in a worker" thing. It is not as easy in HTML as it is in XHR. We should just kill those sections ASAP.
  351. # [17:31] <Domenic> BTW I am having ES take over the stack of scripts basically
  352. # [17:31] <Domenic> It will also work with modules
  353. # [17:31] <Domenic> (This is not in the current PR, it's upcoming)
  354. # [17:31] <Domenic> https://github.com/tc39/ecma262/pull/242
  355. # [17:32] <annevk> Domenic: including script settings?
  356. # [17:32] <annevk> Domenic: or will those remain HTML things?
  357. # [17:33] <Domenic> I think script settings will stay for noe
  358. # [17:34] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: My Mac has gone to sleep. ZZZzzz…)
  359. # [17:35] <Domenic> But each ES script/module will have a [[HostDefined]] slot containing the script settings object. And so ES can track the stack of them.
  360. # [17:36] * Joins: wilsonpage (~wilsonpag@217.111.161.212)
  361. # [17:38] <annevk> https://en.wikipedia.org/wiki/JavaScript#Trademark suggests Mozilla has a license for use of the JavaScript trademark, but the link does not really verify that claim
  362. # [17:42] * Joins: nikkibee (~quassel@node-1w7jr9y93irfpcc68uouqns4d.ipv6.telus.net)
  363. # [17:42] * Joins: dbaron (~dbaron@50-0-128-58.dsl.dynamic.fusionbroadband.com)
  364. # [17:47] <annevk> Domenic: if you instantiate your own Realm don't you get a different kind of global associated with it? But I guess things can be refactored once that actually happens
  365. # [17:48] <Domenic> annevk: hmm perhaps true... but yeah.
  366. # [17:48] * Joins: jensnockert (~jensnocke@84.219.248.21)
  367. # [17:50] * Quits: jensnockert_ (~jensnocke@84.219.248.21) (Ping timeout: 250 seconds)
  368. # [17:52] * Joins: jensnockert_ (~jensnocke@84.219.248.21)
  369. # [17:55] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 256 seconds)
  370. # [17:55] <annevk> Domenic: I made some progress last week btw on figuring out what the setup for Location needs to become and also Window/WindowProxy
  371. # [17:56] <annevk> Domenic: it seems like WindowProxy will need to handle all the security checks currently on Window too
  372. # [17:56] <Domenic> annevk: good to hear yeah... still not sure how to best handle the IDL vs. not-IDL thing
  373. # [17:56] <annevk> Domenic: Location becomes an IDL thing, but IDL will also support redefining internal methods for IDL things
  374. # [17:56] <Domenic> Hmm
  375. # [17:57] <Domenic> One path I thought might work is to define Window + Location in IDL completely but then define WindowProxy + LocationProxy in ES terms
  376. # [17:57] <Domenic> (or, I guess, Window + BackingLocation and WindowProxy + Location)
  377. # [17:57] <Domenic> But by now you are much more familiar with the problem space than I.
  378. # [17:58] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  379. # [17:58] <wanderview> annevk: I guess this is related? https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/bpbq0Rcpauk
  380. # [17:59] <wanderview> maybe we don't need that level of granularity any more?
  381. # [18:02] * Quits: yoav (~yoav@2.22.226.14) (Remote host closed the connection)
  382. # [18:13] <annevk> wanderview: that's not related
  383. # [18:14] * Quits: davve (~user@h-72-179.a137.corp.bahnhof.se) (Ping timeout: 245 seconds)
  384. # [18:14] * Joins: ap (~ap@17.202.44.214)
  385. # [18:14] <annevk> wanderview: that's some legacy stuff, older names for "loaded" and "total" https://xhr.spec.whatwg.org/#interface-progressevent
  386. # [18:18] * Quits: wilsonpage (~wilsonpag@217.111.161.212) (Quit: My Mac has gone to sleep. ZZZzzz…)
  387. # [18:30] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  388. # [18:33] * Joins: psy_ (~psy@43.224.156.122)
  389. # [18:33] * Quits: psy_ (~psy@43.224.156.122) (Max SendQ exceeded)
  390. # [18:33] * Joins: smaug____ (~chatzilla@dyxxlkyyyyyyyyyyyyyby-3.rev.dnainternet.fi)
  391. # [18:33] * Joins: psy_ (~psy@43.224.156.122)
  392. # [18:49] * Joins: svl (~me@86.81.103.1)
  393. # [18:50] * Quits: myakura (uid22370@gateway/web/irccloud.com/x-gffcrzopqwejzqdt) (Quit: Connection closed for inactivity)
  394. # [18:51] * Quits: calvaris (~calvaris@fanzine.igalia.com) (Quit: Ex-Chat)
  395. # [18:55] * Joins: bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net)
  396. # [18:59] * Joins: bholley (~bholley@c-73-231-198-151.hsd1.ca.comcast.net)
  397. # [19:07] * Quits: adactio (~adactio@185.65.110.45) (Quit: adactio)
  398. # [19:10] * Quits: Ms2ger (~Ms2ger@ptr-2hj4tblvksdoqv3ow00nxht4s.ip6.access.telenet.be) (Quit: nn)
  399. # [19:25] * Quits: espadrine (~tyl@213.152.2.4) (Ping timeout: 250 seconds)
  400. # [19:28] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  401. # [19:29] * Joins: ambv (~ambv@199.201.64.138)
  402. # [19:30] * Joins: paxcoder (~paxcoder@unaffiliated/paxcoder)
  403. # [19:31] <JakeA> wanderview: been bouncing the idea of transactional cache stuff in my head. Starting to settle on something like cache.transactionUntil(promise) - meaning this instance of cache holds a write-lock until the promise settles
  404. # [19:31] <JakeA> (or the instance is GC'd, which could be a sticking point)
  405. # [19:32] <paxcoder> annevk: Hello. Months have passed. It's time for me to ask about UndoManager again. What's up with it, what is its problem? Is it missing a consistency model, is that is? Or is there a simpler reason why it's stuck on the 2012 Niwa draft?
  406. # [19:33] <JakeA> wanderview: I'm moving away from batching, as it doesn't allow you to read from a cache, then do writes based on what you read
  407. # [19:33] <annevk> paxcoder: heh, I'm not sure
  408. # [19:34] <annevk> paxcoder: Gecko reportedly has some implementation of which the state is unclear to me; rniwa left Google and joined Apple and at the same time realigned interests I think
  409. # [19:35] <annevk> paxcoder: so, there's nobody that's working on it, and nobody is really interested in pursuing it as far as I can tell
  410. # [19:36] <paxcoder> That's weird. Esp. with Github's Atom editor and Microsoft's fork.
  411. # [19:37] * Quits: boogyman (~justme_j@pdpc/supporter/professional/boogyman) (Ping timeout: 250 seconds)
  412. # [19:39] <annevk> Well, what does have some traction is a different more low-level approach to editing
  413. # [19:39] <paxcoder> What do you mean?
  414. # [19:39] <annevk> So perhaps if that is done UndoManager can be a thing that is implemented by the application more easily
  415. # [19:39] <annevk> I haven't really followed what is going on since it's not clear to me it's going well, but https://w3c.github.io/editing/
  416. # [19:44] <Domenic> JakeA: you should talk to jsbell; he has ideas around transactions/locking/etc. in general.
  417. # [19:44] <paxcoder> annevk: If I'm silent I'm looking into things, doesn't mean I don't appreciate. FYI
  418. # [19:45] * Quits: darobin (~darobin@209.148.63.66) (Remote host closed the connection)
  419. # [19:46] * Quits: ambv (~ambv@199.201.64.138) (Quit: sys.exit(0) # app closed)
  420. # [19:46] <paxcoder> annevk: BTW. While I'm reading this, I ran into your voice on... what was it.. The Web Platform Podcast perhaps? Idk. Anyway still refreshing my feeds hoping to scoop up a blog post of yours some time.
  421. # [19:46] * Joins: boogyman (~justme_j@173-171-176-46.res.bhn.net)
  422. # [19:46] * Quits: boogyman (~justme_j@173-171-176-46.res.bhn.net) (Changing host)
  423. # [19:46] * Joins: boogyman (~justme_j@pdpc/supporter/professional/boogyman)
  424. # [19:47] <annevk> paxcoder: ah yes, I have an idea for a blog post now, so maybe it'll happen :-)
  425. # [19:48] <annevk> paxcoder: and I did appear on such a podcast once, so perhaps
  426. # [19:48] <JakeA> Domenic: yeah, I know IDB is going with the waitUntil model, but good point about locking. I'd like to get away with write-locking only, but this is where I have less experience.
  427. # [19:48] <annevk> paxcoder: and yeah, I think having UndoManager handled by the browser could definitely help out a bunch of folks, but I think in the end it hasn't been fully tackled since it was too hard and editing in the browser still largely sucks
  428. # [19:49] <annevk> paxcoder: perhaps you can reach out to rniwa on Twitter or IRC somewhere and get a more complete story
  429. # [19:50] <paxcoder> annevk: The looks of these input events remind me of iOS, but iOS has rich string thingies, and the web does not, so I don't see how that helps with syntax highlighting or WYSIWG editors. What will the blog post be about if I may inquire?
  430. # [19:53] * Quits: bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net) (Quit: My Mac has gone to sleep. ZZZzzz…)
  431. # [19:53] * Joins: bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net)
  432. # [19:55] <paxcoder> annevk: does rniwa come here or did you mean some other channel?
  433. # [19:55] * Quits: thinkxl (~thinkxl@unaffiliated/thinkxl) (Quit: My Mac has gone to sleep. ZZZzzz…)
  434. # [19:57] * Quits: bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net) (Client Quit)
  435. # [19:58] <paxcoder> Question for everybody: What do you use instead of caniuse.com?
  436. # [20:00] * paxcoder begins to suspect execCommand may have something to do with the missing richstring feature
  437. # [20:00] * Joins: ap_ (~ap@17.114.217.94)
  438. # [20:01] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  439. # [20:02] * Joins: bengo (~textual@50-203-84-2-static.hfc.comcastbusiness.net)
  440. # [20:03] * Joins: yoav (~yoav@37.165.36.5)
  441. # [20:03] * Quits: ap (~ap@17.202.44.214) (Ping timeout: 240 seconds)
  442. # [20:04] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  443. # [20:04] * Joins: darobin (~darobin@209.148.63.66)
  444. # [20:04] <paxcoder> interesting
  445. # [20:07] * Joins: paxcoder_ (~paxcoder@78.134.141.210)
  446. # [20:10] * Quits: paxcoder (~paxcoder@unaffiliated/paxcoder) (Ping timeout: 250 seconds)
  447. # [20:12] * Joins: eric_carlson (~ericc@17.202.48.68)
  448. # [20:15] * Joins: weinig (~weinig@17.114.219.6)
  449. # [20:16] * Quits: wcpan_ (quassel@wcpan.info) (Remote host closed the connection)
  450. # [20:23] * Quits: weinig (~weinig@17.114.219.6) (Quit: weinig)
  451. # [20:23] * Quits: yoav (~yoav@37.165.36.5) (Ping timeout: 240 seconds)
  452. # [20:31] * Joins: weinig (~weinig@17.114.1.171)
  453. # [20:36] * Quits: ap_ (~ap@17.114.217.94) (Quit: My Mac has gone to sleep. ZZZzzz…)
  454. # [20:37] * Joins: ap (~ap@17.114.217.94)
  455. # [20:40] * Joins: wcpan (~quassel@wcpan.info)
  456. # [20:43] * Quits: dbaron (~dbaron@50-0-128-58.dsl.dynamic.fusionbroadband.com) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  457. # [20:47] * Parts: rits (~richa@117.208.123.143)
  458. # [20:50] * Joins: thinkxl (~thinkxl@unaffiliated/thinkxl)
  459. # [20:56] * Quits: jensnockert_ (~jensnocke@84.219.248.21) (Remote host closed the connection)
  460. # [20:56] * Joins: jensnockert (~jensnocke@84.219.248.21)
  461. # [20:57] * Quits: weinig (~weinig@17.114.1.171) (Quit: weinig)
  462. # [20:59] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  463. # [21:00] * Quits: jensnockert (~jensnocke@84.219.248.21) (Ping timeout: 240 seconds)
  464. # [21:03] <wanderview> JakeA: I'd like to know the real world use case driving transactions for Cache
  465. # [21:05] <wanderview> JakeA: or another way to ask the question... if some needs the complexity of transactional behavior, can they just use IDB?
  466. # [21:14] <wanderview> JakeA: also, I think we already have a transaction mechanism in SW... the install and activate events
  467. # [21:15] <wanderview> maybe thats over stating it, but they fill a similar role
  468. # [21:28] * Quits: ehynds (~ehynds@64.206.121.41)
  469. # [21:31] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  470. # [21:31] * Quits: stalled (~stalled@unaffiliated/stalled) (Ping timeout: 250 seconds)
  471. # [21:36] * Quits: bblfish (~bblfish@86.21.242.52) (Remote host closed the connection)
  472. # [21:53] * Quits: svl (~me@86.81.103.1) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  473. # [21:55] * Quits: ap (~ap@17.114.217.94) (Quit: My Mac has gone to sleep. ZZZzzz…)
  474. # [21:56] * Joins: ap (~ap@17.114.217.94)
  475. # [21:56] * Quits: ap (~ap@17.114.217.94) (Client Quit)
  476. # [22:09] * chrisdickinson_ is now known as chrisdickinson
  477. # [22:11] * Joins: jensnockert (~jensnocke@84.219.248.21)
  478. # [22:12] * Joins: bblfish (~bblfish@cpc2-popl3-2-0-cust563.13-2.cable.virginm.net)
  479. # [22:12] * Joins: dbaron (~dbaron@2620:101:80fb:224:bdea:4495:ec09:ef03)
  480. # [22:13] * Joins: thinkxl_ (~thinkxl@unaffiliated/thinkxl)
  481. # [22:15] * Quits: thinkxl (~thinkxl@unaffiliated/thinkxl) (Ping timeout: 240 seconds)
  482. # [22:24] * Joins: jensnockert_ (~jensnocke@84.219.248.21)
  483. # [22:25] * Quits: jensnockert (~jensnocke@84.219.248.21) (Read error: Connection reset by peer)
  484. # [22:29] * Joins: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5)
  485. # [22:33] * Quits: paxcoder_ (~paxcoder@78.134.141.210) (Quit: leaving)
  486. # [22:33] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  487. # [22:34] * Joins: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com)
  488. # [22:37] * Quits: wbe (~textual@pd95b30f4.dip0.t-ipconnect.de) (Quit: My computer has gone to sleep. ZZZzzz…)
  489. # [22:40] * Joins: weinig (~weinig@17.114.219.6)
  490. # [22:40] * Quits: sicking (~sicking@corp-nat.p2p.sfo1.mozilla.com) (Quit: sicking)
  491. # [22:41] * Joins: rniwa (~rniwa@17.202.48.94)
  492. # [22:43] * Joins: heycam|away (~cam@wok.mcc.id.au)
  493. # [22:52] * Joins: ambv (~ambv@199.201.64.138)
  494. # [22:53] * Quits: weinig (~weinig@17.114.219.6) (Quit: weinig)
  495. # [22:56] * Joins: wilsonpage (~wilsonpag@cpc73846-dals21-2-0-cust279.20-2.cable.virginm.net)
  496. # [22:58] * Joins: weinig (~weinig@17.114.219.6)
  497. # [22:59] * Joins: sicking (~sicking@63.245.219.53)
  498. # [22:59] * Quits: weinig (~weinig@17.114.219.6) (Client Quit)
  499. # [23:01] * Quits: encryptd_fractal (~encryptd_@63-254-58-198.ip.mcleodusa.net) (Remote host closed the connection)
  500. # [23:01] * Quits: frivoal (~frivoal@2400:2650:86c0:a500:4c94:a2b6:d2ce:99c5) (Ping timeout: 250 seconds)
  501. # [23:02] * Joins: bradleymeck (~bradleyme@cpe-70-112-190-128.austin.res.rr.com)
  502. # [23:03] * Joins: weinig (~weinig@17.114.219.6)
  503. # [23:04] * Quits: roc (~chatzilla@121.98.188.221) (Ping timeout: 240 seconds)
  504. # [23:05] * Quits: bradleymeck (~bradleyme@cpe-70-112-190-128.austin.res.rr.com) (Client Quit)
  505. # [23:08] * Quits: zecho (~zecho@78-247-17-199.northern.mnscu.edu) (Ping timeout: 240 seconds)
  506. # [23:10] * Joins: wbe (~textual@port-7480.pppoe.wtnet.de)
  507. # [23:11] * Quits: jensnockert_ (~jensnocke@84.219.248.21) (Remote host closed the connection)
  508. # [23:11] * Joins: bradleymeck (~bradleyme@cpe-70-112-190-128.austin.res.rr.com)
  509. # [23:12] * Joins: yoav (~yoav@sdo26-1-78-245-148-181.fbx.proxad.net)
  510. # [23:15] * wilsonpage is now known as wilsonpage-away
  511. # [23:19] * Joins: espadrine (~tyl@88.166.187.54)
  512. # [23:21] * Joins: svl (~me@86.81.103.1)
  513. # [23:30] * Quits: wilsonpage-away (~wilsonpag@cpc73846-dals21-2-0-cust279.20-2.cable.virginm.net) (Ping timeout: 256 seconds)
  514. # [23:31] * Quits: [sarrri] (~sari@unaffiliated/sarri) (Quit: [~sarri])
  515. # [23:32] * Quits: eric_carlson (~ericc@17.202.48.68) (Ping timeout: 256 seconds)
  516. # [23:36] * Quits: weinig (~weinig@17.114.219.6) (Quit: weinig)
  517. # [23:41] * Quits: plutoniix (~q@node-1bey.pool-101-108.dynamic.totbb.net) (Quit: จรลี จรลา)
  518. # [23:45] * Quits: TallTed (~Thud@c-98-216-254-6.hsd1.ma.comcast.net)
  519. # [23:46] * Quits: mven (~textual@32.97.110.56) (Ping timeout: 240 seconds)
  520. # [23:48] * Quits: svl (~me@86.81.103.1) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  521. # [23:51] * thinkxl_ is now known as thinkxl
  522. # [23:53] * Joins: karlcow (~karl@nerval.la-grange.net)
  523. # [23:57] * Quits: ttepasse (~ttepasse@ip-178-200-61-79.hsi07.unitymediagroup.de) (Quit: Textual IRC Client: www.textualapp.com)
  524. # Session Close: Tue Dec 15 00:00:00 2015

Previous day, Next day

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