/irc-logs / freenode / #whatwg / 2010-07-25 / end

Options:

  1. # Session Start: Sun Jul 25 00:00:00 2010
  2. # Session Ident: #whatwg
  3. # [00:03] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  4. # [00:04] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  5. # [00:07] * Quits: Peter`- (~peter@h89030.upc-h.chello.nl) (Ping timeout: 245 seconds)
  6. # [00:09] * Joins: beverloo (~peter@h89030.upc-h.chello.nl)
  7. # [00:21] * Quits: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  8. # [00:33] <jgraham> http://hg.hoppipolla.co.uk/hgwebdir.cgi/websrtjs/
  9. # [00:33] <jgraham> WebSRT parser
  10. # [00:33] <jgraham> Probably *horribly* buggy
  11. # [00:33] * Quits: seventh (galofort@208.98.1.237) (Ping timeout: 245 seconds)
  12. # [00:34] <jgraham> Doesn't actually do anything useful yet (like, say, display captions)
  13. # [00:34] <jgraham> Just parses the SRT file
  14. # [00:35] * Quits: beverloo (~peter@h89030.upc-h.chello.nl) (Ping timeout: 265 seconds)
  15. # [00:35] <jgraham> Also doesn't create real DOM nodes yet
  16. # [00:41] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  17. # [00:47] * Joins: miketaylr (~miketaylr@24.42.95.108)
  18. # [00:49] * Quits: miketaylr (~miketaylr@24.42.95.108) (Remote host closed the connection)
  19. # [00:56] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  20. # [01:05] * Quits: svl (~me@ip565744a7.direct-adsl.nl) (Quit: And back he spurred like a madman, shrieking a curse to the sky.)
  21. # [01:05] * Joins: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com)
  22. # [01:08] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  23. # [01:21] * Quits: colapop (~colapop@68-190-151-103.dhcp.eucl.wi.charter.com) (Ping timeout: 240 seconds)
  24. # [01:22] * Joins: colapop (~colapop@68-190-151-103.dhcp.eucl.wi.charter.com)
  25. # [01:28] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Ping timeout: 276 seconds)
  26. # [01:28] * Quits: tndH (~Rob@adsl-87-102-89-10.karoo.KCOM.COM) (Quit: ChatZilla 0.9.86-rdmsoft [XULRunner 1.9.0.1/2008072406])
  27. # [01:29] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  28. # [01:41] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  29. # [01:45] * Quits: ukd1 (~russ@post.ukd1.co.uk) (Ping timeout: 240 seconds)
  30. # [01:45] * Joins: ukd1 (~russ@post.ukd1.co.uk)
  31. # [01:52] * Quits: oal (~oal@5.79-160-122.customer.lyse.net) (Remote host closed the connection)
  32. # [01:52] * Quits: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com) (Ping timeout: 245 seconds)
  33. # [02:17] <Hixie> jgraham: btw, i'll probably comment out the vertical text stuff soon since CSS doesn't yet define how to render it
  34. # [02:26] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  35. # [02:27] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  36. # [02:37] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  37. # [02:38] * Joins: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp)
  38. # [02:39] * Joins: TelFiRE (~TelFiRE@c-24-10-155-57.hsd1.ut.comcast.net)
  39. # [02:55] * Quits: EclipseGc (~EclipseGc@mds-65-64-83-45.meridiandata.com) (Quit: EclipseGc)
  40. # [03:04] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  41. # [03:32] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: This computer has gone to sleep)
  42. # [03:44] * Joins: seventh (seventh@64-9-157-128.fwd.datafoundry.com)
  43. # [03:50] * Quits: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de) (Quit: ⌘Q)
  44. # [04:01] * Joins: erlehmann_ (~erlehmann@dslb-092-078-133-222.pools.arcor-ip.net)
  45. # [04:03] * Quits: FireFly (~firefly@unaffiliated/firefly) (Quit: swatted to death)
  46. # [04:04] * Quits: erlehmann (~erlehmann@dslb-188-103-027-237.pools.arcor-ip.net) (Ping timeout: 245 seconds)
  47. # [04:07] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  48. # [04:12] * Quits: colapop (~colapop@68-190-151-103.dhcp.eucl.wi.charter.com) (Ping timeout: 245 seconds)
  49. # [04:12] * Joins: titacgs (~titacgs@201.250.167.101)
  50. # [04:13] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  51. # [04:14] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  52. # [04:16] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  53. # [04:21] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  54. # [04:22] * Joins: kennyluck (~kennyluck@EM114-51-210-19.pool.e-mobile.ne.jp)
  55. # [04:43] * Quits: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net) (Ping timeout: 240 seconds)
  56. # [04:55] * Joins: cyphase (~cyphase@adsl-99-191-72-252.dsl.pltn13.sbcglobal.net)
  57. # [05:11] * Joins: EclipseGc (~EclipseGc@ip68-12-160-21.ok.ok.cox.net)
  58. # [05:13] <micheil> Hixie: websockets: ready for public comsumption by the end of the year?
  59. # [05:13] <micheil> (or hopefully ready)
  60. # [05:18] * Quits: titacgs (~titacgs@201.250.167.101) (Ping timeout: 248 seconds)
  61. # [05:32] * Quits: kennyluck (~kennyluck@EM114-51-210-19.pool.e-mobile.ne.jp) (Quit: kennyluck)
  62. # [05:41] * Quits: shepazu (~schepers@adsl-69-180-215.rmo.bellsouth.net) (Quit: Core Breach)
  63. # [05:41] <aho> mmm... websockets... nom nom :v
  64. # [05:54] <Hixie> micheil: i'm not aware of any known issues, but the hybi wg seems to have a lot of members who basically want to start over
  65. # [05:55] <micheil> Hixie: please not.
  66. # [05:55] <micheil> Hixie: just wanted to give you a heads up on: http://plancast.com/a/40wi/record_episode_030_-_websockets_freenode_thechangelog_saturday_july_31_2010_500pm
  67. # [05:56] <Hixie> i have no idea what i'm looking at :-)
  68. # [05:57] <micheil> okay, basically a popular opensource oriented podcast is doing an episode on websockets, and their current usage
  69. # [05:57] <Hixie> if you don't want the hybi wg to change everything, i recommend saying so on the list -- right now there seems to be a lot of people who have said they think the protocol shouldn't be designed for amateurs, and if that isn't a requirement, the protocol would be radically different
  70. # [05:57] <micheil> it's being recorded next weekend
  71. # [05:57] <Hixie> ah, nice
  72. # [05:57] <micheil> quite frankly, I don't think it's a protocol designed for ametuers
  73. # [05:57] <micheil> *amatuers
  74. # [05:58] <Hixie> well it might not succeed, but it is designed for them :-)
  75. # [05:58] <Hixie> if i wasn't designing with amateurs in mind, i'd just do it always TLS, and support things like multiplexing built-in
  76. # [06:00] <micheil> well, really, do we need TLS on always?
  77. # [06:00] <micheil> I mean, saying that could imply that HTTP was designed with amateurs in mind
  78. # [06:03] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  79. # [06:04] <micheil> Hixie: isn't TLS fairly expensive to achieve?
  80. # [06:04] <micheil> ie. meaning that websockets with TLS wouldn't be a disposable transport
  81. # [06:50] <Hixie> TLS isn't really that expensive relative to other costs involved in a long-lived connection at this point, as I understand it
  82. # [06:50] <Hixie> the main cost of TLS, as I understand it, is connection setup and the block-based encryption which increases latency of short bits, but the latter could presumably be worked around easily enough
  83. # [06:51] <Hixie> (this is not my area of expertise, though)
  84. # [06:51] <Hixie> i've no idea what HTTP's design criteria were
  85. # [06:51] <Hixie> but at this point HTTP certainly isn't trivially implementable if you want a complete conforming implementation, either on the client or on the server
  86. # [07:09] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  87. # [07:30] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  88. # [07:44] * Quits: ukai (~ukai@220.109.219.244) (Ping timeout: 265 seconds)
  89. # [07:49] * Quits: EclipseGc (~EclipseGc@ip68-12-160-21.ok.ok.cox.net) (Quit: EclipseGc)
  90. # [08:09] * Quits: hamcore (rhythm@unaffiliated/msmosso)
  91. # [08:13] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  92. # [08:16] <othermaciej> Hixie: out of curiosity, are there any existing protocols that are simple enough to be implemented by amateurs?
  93. # [08:16] <othermaciej> (either client or sever sides thereof)
  94. # [08:16] <Hixie> not a network protocol, but CGI
  95. # [08:17] <othermaciej> that's definitely an example where stock servers implemented a network protocol and exposed a simpler semi-standardized interface for hand-rolled software to plug in
  96. # [08:17] <micheil> I think we should really drop the idea that websockets are easy.
  97. # [08:17] <micheil> it's up to the implementors of the protocol to make it easy to work with.
  98. # [08:17] <micheil> but the protocol itself doesn't need to be easy for developers
  99. # [08:17] <micheil> (if that makes sense)
  100. # [08:18] <Hixie> i think that assumes that the developers and the implementors of the protocol are going to be distinct
  101. # [08:18] <micheil> well, I'm making that distinction
  102. # [08:18] <othermaciej> I think citing CGI as an example would tend to argue that Websockets should also follow the CGI model to solve the "amateur" use case
  103. # [08:18] <othermaciej> I wonder if there is any case of a network protocol that is widely implemented directly from scratch
  104. # [08:18] <micheil> if you make a web app, you're probably not also writing the http server to power it.
  105. # [08:19] <Hixie> only because http is so hard to implement
  106. # [08:19] <micheil> you're probably using nginx, apache or something like that.
  107. # [08:19] <micheil> so, the people that write the things to work with the protocol are the implementors, the developers are the ones that use implementations to make awesome stuff
  108. # [08:19] <Hixie> my point is that the only reason we don't see people implementing protocols so often is that they're hard to implement
  109. # [08:19] <othermaciej> the IRC protocol has been implemented many times I guess, does it tend to get implemented from scratch by people whose main goal is something besides just "implement IRC"?
  110. # [08:20] <othermaciej> IRC bots tend to talk IRC directly, but I have no idea if people use libraries to implement them
  111. # [08:20] <micheil> I mean, when people first started catching on to websockets and node.js, there were about 10 different implementations, all of which didn't actually implement the protocol to specification
  112. # [08:22] <othermaciej> If there is no existing example of a protocol people often implement from scratch just to make a piece of toy software, then it may be that there is in fact no such thing, and then it would be pointless to try to serve that use case
  113. # [08:22] <Hixie> that's tautological
  114. # [08:23] <othermaciej> if there are examples of such protocols, then they could be useful for convincning people that it's a worthwhile property of a protocol
  115. # [08:23] <Hixie> that line of argumentation regresses to nobody ever trying
  116. # [08:24] <othermaciej> has anyone ever tried before?
  117. # [08:24] <othermaciej> if so, have they succeeded or failed?
  118. # [08:24] <Hixie> not to my knowledge
  119. # [08:24] <othermaciej> what can we learn from their attempts?
  120. # [08:25] <Hixie> i'm not aware of any attempt to design a protocol that is purposefully kept simple enough that it is possible for amateurs to implement it in a few days other than CGI
  121. # [08:25] <Hixie> (on the server side)
  122. # [08:25] <Hixie> (obviously on the client side we've designed tons of APIs that way, that's what the web is made of)
  123. # [08:25] <othermaciej> CGI is not a network protocol though
  124. # [08:25] <othermaciej> it's a design intended to hide the complexity of what was, at the time, a very simple protocol
  125. # [08:27] <othermaciej> sure, but APIs aren't really comparable to network protocold
  126. # [08:27] <Hixie> why not?
  127. # [08:29] <othermaciej> because you don't have to build your intraction with them out of low-level primitives like select() and read()
  128. # [08:29] <othermaciej> the DOM is a significantly higher-level abstraction than Unix system calls
  129. # [08:30] <Hixie> *shrug*
  130. # [08:30] <Hixie> i don't buy that that matters
  131. # [08:31] <othermaciej> I think the reason people don't build network protocols from scratch is not because every existing protocol is too complicated but rather because Unix system calls are too low-level an abstraction to be convenient
  132. # [08:31] <othermaciej> as supporting evidence, I would cite the fact that amateurs rarely write *any* software that directly interacts with Unix system calls
  133. # [08:31] <Hixie> come now, it's not that hard
  134. # [08:32] <othermaciej> I would say you have zero evidence for the assertion that it's "not that hard"
  135. # [08:32] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 240 seconds)
  136. # [08:32] <Hixie> not sure what would count as evidence
  137. # [08:33] <othermaciej> examples of types of code that amateurs often write from scratch using read/write/select or a similarly low-level interface
  138. # [08:33] <Hixie> i'm not a professional programmer and i've had minimal trouble implementing network code in multiple languages
  139. # [08:34] <othermaciej> I think the "amateur programmers" you are concerned about are at least 3 standard deviations below you on the IQ scale
  140. # [08:34] <othermaciej> so I would not accept "not hard for Ian Hickson" as evidence
  141. # [08:35] <othermaciej> unless your goal is just to make something simple to implement for people 3 or 4 standard deviations above the mean IQ who happen not to be paid primarily to program
  142. # [08:35] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  143. # [08:36] <Hixie> i don't know of any situation before websockets where what you describe as suitable evidence would have come up
  144. # [08:36] <othermaciej> well there's lots of things you *could* do with raw Unix syscalls
  145. # [08:36] <Hixie> like what?
  146. # [08:37] <othermaciej> it just happens that in every case where that is a possibility, the vast majority of people use higher-level libraries
  147. # [08:37] <Hixie> even with websockets i expect most people to use libraries, that doesn't mean we should not cater for people who don't use libraries
  148. # [08:37] <othermaciej> three examples: implementing the "load" or "save" feature of a random toy application; reading config files; launching applications
  149. # [08:37] <Hixie> most web APIs are abstracted out by libraries too
  150. # [08:38] <Hixie> if it makes you more willing to accept it as a requirement, we can also phrase it as "keep the protocol as simple as possible to limit the number of bugs that professional programmers make"
  151. # [08:39] <micheil> Hixie: as long as it's implementable by reading the spec and as long as I don't need a ITC doctorate + phd to understand it, I'm cool.
  152. # [08:39] <Hixie> just look at the mess "professional programmers" have made of simple APIs like postMessage() or simple protocols like HTTP
  153. # [08:39] <othermaciej> let's say we accepted the premise that no matter what the protocol design is, .01% of people will implement from scratch instead of using a library - would it then be useful to cater to the "direct implementation" use case?
  154. # [08:39] <othermaciej> I totally agree that the protocol should be as simple as possible to limit bugs
  155. # [08:39] <othermaciej> it's already kind of scary complicated on the client side
  156. # [08:39] <othermaciej> I only find that acceptable because significant complexity is needed just to make it secure
  157. # [08:40] <Hixie> my goal is just to have the protocol be trivial, i don't really care if we phrase it as "cater to amateurs" or "limit bugs that libraries will have" or whatnot, it's all the same result in practice
  158. # [08:40] * Joins: colapop (~colapop@68-190-151-103.dhcp.eucl.wi.charter.com)
  159. # [08:40] <Hixie> i just find it easier to think about what concretely is simple or not when i consider a hypothetical amateur programmer than when i just think of keeping it "simple"
  160. # [08:41] <othermaciej> no matter what your goal is, you should not use a fallacious argument as the public justification for it
  161. # [08:41] <othermaciej> I do think there are material differences in the two standards though
  162. # [08:41] * Quits: Amorphous (jan@unaffiliated/amorphous) (Ping timeout: 260 seconds)
  163. # [08:41] <Hixie> (a third way of phrasing it is that the protocol should be as minimal a layer above TCP as possible, since we're just trying to do TCP for the Web)
  164. # [08:42] <othermaciej> for the hypothetical "professional programmer who might make mistakes", a requirement to use a TLS library would be no greater a burden than a requirement to use TCP
  165. # [08:42] <Hixie> that's clearly not the case
  166. # [08:42] <Hixie> the number of buggy TLS configurations on the web is clear evidence of how wrong that is
  167. # [08:43] <othermaciej> is it greater than the number of buggy non-TLS configurations on the Web?
  168. # [08:43] <othermaciej> (not sure how to compare, since I do not know what you mean by "buggy configration")
  169. # [08:44] <Hixie> i have no idea what your question means
  170. # [08:44] <othermaciej> anyway, I bet if you proposed a standard of "as simple as possible, to limit the mistakes made even by professional/expert implementors", in place of "simple enough for amateurs", I bet nearly everyone would agree
  171. # [08:44] <Hixie> i mean things like self-signed certs, wrong certs, etc
  172. # [08:44] <othermaciej> evn if you think the two standards are equivalent in practice
  173. # [08:44] <othermaciej> I see
  174. # [08:45] <othermaciej> surely you can't count those kinds of things as programming errors
  175. # [08:45] <Hixie> making TLS libraries do the right thing is orders of magnitude more complex than making select() do the right thing
  176. # [08:45] <othermaciej> the people who programmed Apache have nothing to do with what kind of cert you put on your server
  177. # [08:45] <Hixie> you're the editor of the requirements doc, i'll let you deal with justifying it :-)
  178. # [08:45] <othermaciej> I'm trying to quit!
  179. # [08:46] <othermaciej> but fine, I will propose that wording and see who objects
  180. # [08:46] <Hixie> the protocol i'm designing is a trivially-implementable TCP for web browsers
  181. # [08:46] <Hixie> if that's what hybi wants, it's what they'll get
  182. # [08:46] <Hixie> if it's not, i'll do it elsewhere
  183. # [08:46] <Hixie> we're only doing it in the hybi wg because the ietf told me that they wanted to have the trivially-implementable TCP for web browsers spec i was working on done at the IETF
  184. # [08:47] <Hixie> if they change their mind, I don't really mind
  185. # [08:47] <Hixie> that's up to them
  186. # [08:47] <Hixie> so i don't really feel the need to justify this particular aspect of the design; for me, it's a given
  187. # [08:47] <othermaciej> shouldn't your goals be driven by use cases?
  188. # [08:48] <Hixie> who said they weren't?
  189. # [08:48] <Hixie> the use case collection for this stuff happened years ago
  190. # [08:48] <Hixie> around 2005
  191. # [08:48] <othermaciej> you seem to be saying that you have some standard of "trivially implementable" that you are not willing to revise based on arguments or data, and which is not clearly driven by a realistic use case
  192. # [08:49] <Hixie> http://www.w3.org/TR/html-design-principles/#avoid-needless-complexity
  193. # [08:50] <colapop> For a site like Wikipedia, would it be "semantic" to put the nav links for article/discussion/edit/history/etc. within the <article> element?
  194. # [08:50] <Hixie> colapop: yes
  195. # [08:50] <othermaciej> Sure, but that's no reason not to http://www.w3.org/TR/html-design-principles/#solve-real-problems
  196. # [08:50] <Hixie> we are
  197. # [08:50] <othermaciej> you said that if you didn't have this "amateur programmer" standard, you would make at least two changes which could solve real problems
  198. # [08:50] <othermaciej> (require TLS, include multiplexing)
  199. # [08:51] <micheil> seriously, why do we want TLS?
  200. # [08:51] <micheil> I see pretty much 0 benefit.
  201. # [08:51] <micheil> do most people browser the web always using https?
  202. # [08:51] <estellevw> is it <event-source> or <eventsource>
  203. # [08:51] <othermaciej> micheil: two basic reasons
  204. # [08:52] <micheil> othermaciej: please, do explain.
  205. # [08:52] <othermaciej> micheil: (1) it's much easier to get through a proxy with SSL over port 443 rather than non-SSL over port 80, with a bidirectional protocol
  206. # [08:52] <Hixie> othermaciej: i consider not having the keep-it-simple standard as equivalent to not having to worry about use cases, in which case i'd be designing a protocol for aethetics and theory, not real problems
  207. # [08:52] <othermaciej> (Google gathered some data and found only about a 60% success rate over port 80)
  208. # [08:52] <micheil> actually, there will be a larger dataset coming out soon on websocket support.
  209. # [08:52] <Hixie> othermaciej: i hadn't really considered that there might be people who want to "solve real problems" without also keeping the protocol as simple as possible
  210. # [08:53] <micheil> I can't say much more then that at the moment though
  211. # [08:53] <Hixie> estellevw: neither
  212. # [08:53] <othermaciej> Hixie: I think the standard should be "as simple as possible while addressing the most important (80% use case) problems"
  213. # [08:53] <Hixie> othermaciej: sure, that's what websockets is for
  214. # [08:54] <Hixie> estellevw: (the element is gone, now it's just an API)
  215. # [08:54] <micheil> I would actually do a test on a highly proxied & filtered network, but alias, the network actually blocks all my own domains.
  216. # [08:54] <othermaciej> micheil: (2) it's much easier to design a protocol that you can be confident won't cause security problems for existing Web servers if it's built on top of TLS
  217. # [08:54] <estellevw> thanks hixie.
  218. # [08:54] <micheil> (this network would be the NSW Department of Education network, which I have been told is one of the most highly filtered networks around)
  219. # [08:55] <othermaciej> Hixie: that standard is clearly *not* equivalent to "trivially implementable from scratch" or "simple enough for an amateur to implement"
  220. # [08:55] <micheil> othermaciej: (2) not really.
  221. # [08:55] <Hixie> othermaciej: i don't see any concrete difference
  222. # [08:55] <othermaciej> Hixie: that standard would say, if there is a useful piece of functionality that puts the feature out of reach of amateur implementors, you add it anyway
  223. # [08:55] <Hixie> othermaciej: no
  224. # [08:55] <othermaciej> I mean, imagine the version of <video> that is simple enough for amateurs to implement
  225. # [08:55] <micheil> If I'm going to have to implement TLS, I'm going to find it damn hard; and if you get it wrong, then what's the good?
  226. # [08:55] <othermaciej> it would be pretty useless
  227. # [08:56] * Joins: Amorphous (jan@unaffiliated/amorphous)
  228. # [08:56] <Hixie> othermaciej: ok, i do think that websocket should be implementable by a broader range of people than something aimed exclusively at web browser vendors
  229. # [08:56] <micheil> othermaciej: besides, if you really want security: use the ssl / wss upgrade.
  230. # [08:56] <micheil> connect using SSL.
  231. # [08:57] <othermaciej> micheil: you're going to have to trust me that (2) is true, but I don't have the time right now to explain security against cross-protocol attacks in detail
  232. # [08:57] <Hixie> othermaciej: for example, i think the ConnectionPeer protocol, whatever that ends up being, can easily be orders of magnitude more complex to implement than WebSockets, since it only needs to be implemented a few times, mainly by browser vendors, maybe a couple of times for stand-alone servers
  233. # [08:57] <othermaciej> Hixie: pro browser vendors are definitely not immune to mistakes :-)
  234. # [08:58] <micheil> othermaciej: seriously, how often do you see someone cross-protocol attacking one of your servers. Not to say it doesn't happen. but I just think it's fairly rare.
  235. # [08:58] <othermaciej> but I agree that the client side of Web protocols is likely to be implemented fewer times
  236. # [08:58] <Hixie> othermaciej: but WebSockets is likely to be implemented many orders of magnitude more times than that; for one, i'd expect every programming language to end up with a library to implement it
  237. # [08:58] * Quits: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net) (Quit: nimbupani)
  238. # [08:58] <Hixie> othermaciej: they're not immune to mistakes but they get FAR more testing
  239. # [08:58] <Hixie> than your average custom server
  240. # [08:58] <othermaciej> I think "Server side of a Web network protocol" falls somewhere between "client-side implementation of something Web-facing" and "use of a Web API" in maximum acceptable complexity
  241. # [08:58] <Hixie> or scripting library
  242. # [08:59] <micheil> actually, from what I've heard, a fair few people in the php community have already found draft76 too hard to implement, so they've turned to using things like node.js + node-websocket-server
  243. # [08:59] <othermaciej> based just on number of people likely to do it
  244. # [08:59] <Hixie> micheil: yeah, we've had several people come here in #whatwg asking for help because it's too complex already
  245. # [08:59] <Hixie> micheil: that's one reason i am so reluctant to go any further and add more complexity
  246. # [09:00] <micheil> I think my own websocket library, while not up to 100% spec, I think it's at about 80-90%
  247. # [09:00] <Hixie> micheil: i'd love to find way to make it simpler, but i can't see how to do so while still hitting the 80% othermaciej mentions
  248. # [09:00] <othermaciej> I think for this particular protocol, the security requirements are in major tension with ease of implementation
  249. # [09:00] <Hixie> clearly
  250. # [09:01] <othermaciej> it's unfortunate that client-side security concerns have to be in tension with ease of implementation for servers
  251. # [09:01] <othermaciej> I think multiplexing could be added in a way that it has zero impact on servers that don't want it
  252. # [09:01] <othermaciej> but it would add a *lot* of complexity for clients
  253. # [09:01] <othermaciej> and significant security risk
  254. # [09:01] <othermaciej> I don't think it would have some of the benefits people imagine either
  255. # [09:02] <Hixie> multiplexing is pointless to add at the protocol level
  256. # [09:02] <othermaciej> to really reduce the rate of keepalive pings, you need to consolidate keepalives for connections to multiple servers
  257. # [09:02] <Hixie> it's easy to add at the application layer for people who want it
  258. # [09:02] <Hixie> and TCP doesn't have it
  259. # [09:02] <Hixie> do you know why we can't use TCP keepalives, btw?
  260. # [09:03] <othermaciej> does TCP have keepalives?
  261. # [09:03] <othermaciej> I don't think it does
  262. # [09:03] <Hixie> sure, just send an empty packet
  263. # [09:03] <micheil> seriously, I only just understand what multiplexing is, but I can't see how I'd benefit from using it at a web developer level
  264. # [09:03] <othermaciej> well, it doesn't have built-in passive keepalives
  265. # [09:03] <othermaciej> clearly you could use an empty TCP packet as a WebSocket keepalive
  266. # [09:04] <othermaciej> or at least, I can't think of a reason why not
  267. # [09:04] <othermaciej> however, the problem I would worry about is, what if you have WebSocket connections open to 10 different servers
  268. # [09:04] <othermaciej> that's more likely than 10 connections to 1 server
  269. # [09:04] <othermaciej> it sucks that you have to send a bunch of packets
  270. # [09:05] <othermaciej> seems like it could be avoidable in principle if you are talking to all 10 servers through a single proxy
  271. # [09:05] <micheil> othermaciej: so far I've never noticed a client sending empty packets just to keep the socket alive.
  272. # [09:05] <othermaciej> (my understanding is that keepalive is needed primarily to keep intermediaries from severing the connection)
  273. # [09:05] <micheil> but I am some what abstracted from the network level api
  274. # [09:05] <Hixie> i don't really see much point in keepalives personally
  275. # [09:06] <Hixie> but they're easily done at the application layer also
  276. # [09:06] <micheil> Hixie: agreed.
  277. # [09:06] <Hixie> so if people have subprotocols that don't send much data, they can do it easily
  278. # [09:06] <othermaciej> is there such a thing as a use of WebSocket where you will provably never need keepalives?
  279. # [09:06] <micheil> it just makes application logic slightly more complicated.
  280. # [09:06] <Hixie> frankly though if you're sending so little data that you need keepalives, i'd strongly recommend considering whether HTTP might not solve your needs better
  281. # [09:07] <Hixie> othermaciej: sure, any game where you send state regularly, for instance
  282. # [09:07] <Hixie> othermaciej: or anything where the server sends regular updates
  283. # [09:07] <micheil> or for a chat server
  284. # [09:07] <micheil> or other realtime interaction
  285. # [09:08] <micheil> there's been talk already in the serverside javascript movement of an end-to-end javascript static, with websockets being the communication medium
  286. # [09:08] <othermaciej> I don't understand enough about the problem that keepalives try to prevent
  287. # [09:08] <Hixie> keepalives as i understand it basically solve the problem of NATs thinking your connection is old and thus forgetting about it
  288. # [09:09] <othermaciej> I think if you are waiting for the server to notify you, and both the client and the server have nothing to send for a while, you definitely need keepalives, and using HTTP you will still need them
  289. # [09:09] <Hixie> so they stop routing packets properly
  290. # [09:09] <Hixie> if you're just waiting for server notifications, EventSource is likely more up your alley, and the server can send regular "no updates yet" messages if necessary
  291. # [09:10] <micheil> EventSource does look interesting, especially for push-only events
  292. # [09:10] <othermaciej> if the client could possibly gain enough knowledge of network topology to avoid the need of keepalives, that too would be a possible reason to have them built-in
  293. # [09:10] <micheil> there's actually a library that's combining things like bayuex, websockets, eventsource, etc into one communication medium, which is kind of interesting
  294. # [09:11] <micheil> othermaciej: so far I've not needed to even touch keepalives.
  295. # [09:11] <othermaciej> eventsource is neat because it's trivial to deploy
  296. # [09:11] <othermaciej> you can just use your favorite web stack and there's no need to worry about weird network configurations
  297. # [09:14] * Joins: roc (~roc@121.98.230.221)
  298. # [09:17] <micheil> which should be what websockets should be.
  299. # [09:17] <micheil> all you should need in order to use websockets is a server with some application level logic + a client that connects.
  300. # [09:27] <othermaciej> unfortunately, it's more complicated than that :-(
  301. # [09:30] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  302. # [09:35] * Quits: roc (~roc@121.98.230.221) (Quit: roc)
  303. # [09:35] * Joins: ksemeks (~ksemeks@alpha.linux.hr)
  304. # [09:36] <micheil> othermaciej: it shouldn't have to be.
  305. # [09:42] <ksemeks> is there a book or something about html5/js ?
  306. # [09:45] <micheil> ksemeks: no, but there is a really good course being done by John Allsopp over at sitepoint
  307. # [09:45] <micheil> http://courses.sitepoint.com/html5-live
  308. # [09:45] <micheil> (well, I don't know of a book)
  309. # [09:46] <micheil> as for javascript, take your pick of books.
  310. # [09:46] <micheil> javascript's a massive thing, and a powerful language, if you use it right.
  311. # [09:47] <ksemeks> i picked 'Javascript: The definitive guide', of OReaily
  312. # [09:48] <ksemeks> is there a better one, ? ..
  313. # [09:53] <micheil> that's a pretty good book, JavaScript: The good parts is also good.
  314. # [09:53] <micheil> the best way to learn javascript is to read javascript
  315. # [09:54] <micheil> (by that, I don't mean trying to read the source code to jquery first up)
  316. # [09:54] <micheil> I mean, try looking at things like the language syntax
  317. # [09:55] <ksemeks> im familiar with the syntax
  318. # [09:55] <micheil> in which case, pick something to do with it.
  319. # [09:56] <micheil> (i think my first javascript thing was making a "webos" because those things were somewhat trendy at the time.)
  320. # [09:56] <ksemeks> ok :)
  321. # [09:58] * Joins: jedmund (~justin@adsl-75-37-35-211.dsl.pltn13.sbcglobal.net)
  322. # [09:59] * Joins: beverloo (~peter@h89030.upc-h.chello.nl)
  323. # [09:59] <micheil> ksemeks: although, start simple.
  324. # [09:59] <micheil> and don't just learn jQuery or another js library, because they may abstract you too far from the language
  325. # [10:01] <cyberix> I wrote a simple example about sending binary data with XHR2. http://cs.helsinki.fi/u/twruottu/binpost.js
  326. # [10:03] <cyberix> I am not sure it works. I just wrote it so I'd have something to show.
  327. # [10:03] * Joins: yutak_home (~kee@U017209.ppp.dion.ne.jp)
  328. # [10:03] <cyberix> Do I need to construct the Blob myself, or should I use some library function for that?
  329. # [10:04] <cyberix> in the example 2/3 of the code is about defining/constructing a blob
  330. # [10:04] <cyberix> having a constructor provided by browser would really help
  331. # [10:05] <micheil> and what exactly is a Blob?
  332. # [10:05] <micheil> because "foo" isn't binary data.
  333. # [10:07] <cyberix> http://dev.w3.org/2006/webapi/FileAPI/#blob
  334. # [10:08] <cyberix> by "foo" I mean 0x66 0x6F 0x6F
  335. # [10:08] <cyberix> that is what it becomes when you turn it into data:,foo
  336. # [10:09] <micheil> okay
  337. # [10:09] <micheil> well, iirc, there aren't any current binary implementations native to javascript
  338. # [10:12] * Quits: colapop (~colapop@68-190-151-103.dhcp.eucl.wi.charter.com) (Remote host closed the connection)
  339. # [10:21] <cyberix> that is not a problem
  340. # [10:21] <cyberix> constructing the blob by hand is
  341. # [10:29] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  342. # [10:33] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  343. # [10:36] * Joins: tndH (~Rob@adsl-87-102-89-10.karoo.KCOM.COM)
  344. # [10:41] * Joins: oal (~oal@5.79-160-122.customer.lyse.net)
  345. # [10:42] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  346. # [10:44] * Joins: ROBOd (~robod@92.86.246.81)
  347. # [10:49] * Quits: yutak_home (~kee@U017209.ppp.dion.ne.jp) (Quit: Ex-Chat)
  348. # [10:49] * Joins: jedmund_ (~justin@c-69-181-105-22.hsd1.ca.comcast.net)
  349. # [10:51] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  350. # [10:51] * Joins: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no)
  351. # [10:53] * Quits: jedmund (~justin@adsl-75-37-35-211.dsl.pltn13.sbcglobal.net) (Ping timeout: 240 seconds)
  352. # [10:53] * jedmund_ is now known as jedmund
  353. # [11:03] * Joins: Maurice (copyman@5ED573FA.cable.ziggo.nl)
  354. # [11:11] * Quits: erlehmann_ (~erlehmann@dslb-092-078-133-222.pools.arcor-ip.net) (Quit: Ex-Chat)
  355. # [11:22] <jgraham> micheil: I don't quite understand your position on websockets. Do you believe it should be easy to implement servers ( the "amateur programmer" requirement). Do you believe it currently succeeds in this goals?
  356. # [11:23] <jgraham> s/goals/goal/
  357. # [11:27] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  358. # [11:27] <jgraham> (those questions are orthogonal i.e. you might believe it is simple currently but need not be)
  359. # [11:27] * Joins: maikmerten (~maikmerte@port-92-201-75-125.dynamic.qsc.de)
  360. # [11:31] * Quits: aho (~nya@fuld-4d00d58b.pool.mediaWays.net) (Quit: EXEC_over.METHOD_SUBLIMATION)
  361. # [12:16] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  362. # [12:22] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 276 seconds)
  363. # [12:27] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  364. # [12:30] * Quits: wakaba (~wakaba@35.72.102.121.dy.bbexcite.jp) (Quit: Leaving...)
  365. # [12:33] * Joins: wakaba (~wakaba@35.72.102.121.dy.bbexcite.jp)
  366. # [12:34] * Joins: svl (~me@ip565744a7.direct-adsl.nl)
  367. # [12:49] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  368. # [12:56] * Quits: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net) (Quit: othermaciej)
  369. # [13:47] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  370. # [14:42] <micheil> jgraham: I believe it's simple enough; I think adding ssl / tls as a requirement would over complicate it
  371. # [14:43] <micheil> I don't see it as a protocol implementable by "the amateur programmer", but rather something that while it does require some background knowledge to implement, it's not super technical. If you read the spec, then all the information is there – it's well documented.
  372. # [14:47] <micheil> adding any form of encryption would be unnecessary for what I think the majority of uses for websockets would be, look at the ways that realtime communication in the browser is currently being used
  373. # [14:47] * Joins: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com)
  374. # [14:48] <micheil> there's a few cases, where, ssl security may be good (such as in analytics applications, or specialised chat applications) but I think for every day use, eg, for the standard chat network, or collaborative tool, I don't think SSL is of much importance
  375. # [14:49] <micheil> and if you have a situation which would be benefited from having encryption, eg, when dealing with business data, then you can add it on, like you do with ssl encryption to HTTP
  376. # [14:50] <micheil> jgraham: in essences, being simple / easy for amateur programmers to implement shouldn't be a requirement, as any protocol can be implemented by an amateur.
  377. # [14:51] <micheil> It's just a matter of how correctly that protocol is implemented.
  378. # [14:52] <micheil> I believe that you shouldn't need a PHD in security or something like that in order to implement it though. Such that the protocol shouldn't have any unneeded complexitty (if this complexity can be dramatically simplified through adequate documentation, I'm fine with that too. )
  379. # [14:52] * Joins: FireFly (~firefly@unaffiliated/firefly)
  380. # [14:53] <micheil> does that make sense?
  381. # [14:54] * Joins: kennyluck (~kennyluck@EM114-51-106-67.pool.e-mobile.ne.jp)
  382. # [15:03] <jgraham> micheil: Ok
  383. # [15:04] <jgraham> micheil: So you are in favour of simplicity as a design goal, but not necessarily with the expression of it as an "amateur programmer" requirement?
  384. # [15:04] <micheil> yes
  385. # [15:04] <micheil> simplicity makes things less likely to break.
  386. # [15:04] <micheil> be it by design or implementation.
  387. # [15:05] <micheil> because the last thing that you want is a specification and protocol that no-one wants to use because it's too complicated to get started with
  388. # [15:06] <micheil> at the same time, I don't expect someone who is entirely knew to programming / the concepts of html to be able to use a websocket server, which is fair enough.
  389. # [15:06] <jgraham> Agreed. I tend to believe that the other requirement that is hidden in the "amateur programmer" description is that one should not need a significant amount of network-protocol-writing experience to make a server implementation
  390. # [15:06] * Quits: nessy (~Adium@124-168-158-57.dyn.iinet.net.au) (Quit: Leaving.)
  391. # [15:07] <micheil> I mean, I'm different to most, in that I actually have some of a background with network protocols, and have tried to implement a few and spent some time at uni learning about them briefly.
  392. # [15:08] <micheil> despite that, I'm no one that's good with high level mathematics, security, etc. It takes a hell of a lot to be able to understand a lot of network security, above the basic measures
  393. # [15:09] <jgraham> It seems to be a theme that having punchy names for design requirements works well for small groups mostly in agreement but works poorly when the size of the group expands
  394. # [15:09] <jgraham> The same thing happened with the HTMLWG
  395. # [15:09] <jgraham> People got hung up over the names for principles rather than their motivations
  396. # [15:10] <jgraham> (of course it is possible to disagree with something when you fully understand the motivation)
  397. # [15:11] <micheil> currently, the websocket protocol, to me seems secure, the only times it's not, are when you can crash a server when sending the wrong packets (which I've done, and it was a server level implementation detail, not a problem with websockets)]
  398. # [15:11] <jgraham> (but there seems to often be a phse of attacking strawmen derived from the name)
  399. # [15:11] <micheil> "phse of attacking strawmen"?
  400. # [15:13] <Philip`> s/phse/phase/
  401. # [15:13] <micheil> yeah, I got that; but what do you mean by it?
  402. # [15:15] <jgraham> micheil: For example on the hybi list people claiming that the amateur programmer requirement implied something like "the protocol has to be implementable by people with IQ 90" and using that to attack the requirement
  403. # [15:16] <micheil> I'd have no idea what my IQ is, but I do know that I'm best to leave security to those that specialise in it, just as I often leave design to those that specialise in it.
  404. # [15:17] <micheil> specifications aren't something you just write for fun because you like theoretical implementations and theoretical problems. You write them because there's actually a problem that needs to be solved and that you want to see it solved for a better future of development
  405. # [15:17] <jgraham> micheil: I have no idea what my IQ is either nor do I want to know, but IQ 85ish is supposed to be 1sigma below the mean so ~15% of people have IQ < 85
  406. # [15:18] <micheil> if you want to come up with 1000 reasons why something is secure, then why do we bother implementing anything, as everything is eventually insecure.
  407. # [15:20] <micheil> for the rest of stuff, we just want a way to more easily build richer web interactions.
  408. # [15:20] <micheil> *rest of us
  409. # [15:20] * micheil is really way too tired tonight.
  410. # [15:20] <jgraham> micheil: Yes, security is difficult. It is hard to know if the Websocket security is good enough currently. I can easilly believe that the TLS proposal has better security properties but it comes at a high cost to implementations
  411. # [15:21] <micheil> I think the overhead of the implementation would be enough to mean that you'd dramatically reduce usage.
  412. # [15:22] <micheil> and like I said: most people browse the web use http (I have actually done fulltime browsing with https, as it circumvented a proxy filter, but that's another story)
  413. # [15:22] <micheil> so, really, if you were to redesign http now, would you make it by default require SSL?
  414. # [15:23] <micheil> rather, TLS
  415. # [15:23] <jgraham> I think a good yardstick for simplicity would be "can I implement websockets in popular scipting langauges using only the stdlib"
  416. # [15:23] <micheil> yes
  417. # [15:24] <jgraham> (not a sufficient condition but a necessary one)
  418. # [15:24] <micheil> (as it is, I actually already depend on openssl for the md5 summing, because the bindings provided in node.js are such)
  419. # [15:27] <micheil> although, if by default you require tls, would that not also mean you'd need a certificate of authority?
  420. # [15:29] <jgraham> Apparently not
  421. # [15:30] <micheil> okay, news to me. I know you can do self-signed certificates, but I do know that a lot of browsers often throw a warning at that.
  422. # [15:33] <jgraham> I am under the impression that the TLS proposal can use TLS in a no-certificate mode
  423. # [15:33] <jgraham> But I am the definition of non-expert here
  424. # [15:33] <micheil> which doesn't really add security then, does it?
  425. # [15:34] <micheil> / if it does, then why on earth do I have to pay hundreds of dollars for a certificate from someone like tharwte
  426. # [15:35] <micheil> *thawte
  427. # [15:36] <jgraham> I believe it is addressing a different security concern
  428. # [15:36] <micheil> I'm totally confused now.
  429. # [15:38] <jgraham> I mentioned the non-expert thing, right?
  430. # [15:38] <jgraham> :)
  431. # [15:38] <micheil> yeah, full disclaimer and all.
  432. # [15:38] <jgraham> I would suggest you ask someone else to explain it because they are less likely to be horribly confused than me
  433. # [15:38] <jgraham> Notably abarth, since it is his proposal
  434. # [15:39] <micheil> to put blankly, given enough knowledge and experience, every protocol is hackable using the simple telnet client or XMLHttpRequest
  435. # [15:39] <micheil> and if not a simple telnet client, then with openssl running as a telnet client
  436. # [15:40] <jgraham> telneting into a WebSockets server is not really hacking it though
  437. # [15:40] <jgraham> In the important sense here
  438. # [15:40] <micheil> well, it is accessing it outside of what it was designed to be used with
  439. # [15:41] <jgraham> Possibly using XMLHttpRequest to access a websockets server would be a problem, but that should be impossible
  440. # [15:41] <jgraham> The main concern is the reverse; using a websockets client to access an SMTP server
  441. # [15:41] <micheil> on draft75 it was more plausible, hence the reason for the sec-* stuff
  442. # [15:41] <micheil> abnd key3
  443. # [15:41] <jgraham> and send spam
  444. # [15:42] <micheil> okay, ten points if you can do that.
  445. # [15:42] <micheil> telnet a SMTP server, send it http headers and see what it does.
  446. # [15:42] <micheil> you'll probably just get your connection closed.
  447. # [15:42] <jgraham> micheil: Apparently it will ignore them
  448. # [15:42] <jgraham> I have a reference for this, wait a moment
  449. # [15:42] <micheil> k
  450. # [15:43] <jgraham> http://www.remote.org/jochen/sec/hfpa/hfpa.pdf
  451. # [15:44] <jgraham> For that reason if you try to POST to port 25 in a browser you will find it is blocked
  452. # [15:44] <micheil> then again, my ISP blocks me from accessing :25
  453. # [15:45] <micheil> and really, if that is the case, then it should be the other protocols that are getting upgrades / patches to fix them against this
  454. # [15:46] <jgraham> That clearly isn't a good enough solution
  455. # [15:46] <micheil> would it be an idea to implement this security at client-side level?
  456. # [15:47] <jgraham> You can't just release a new protocol which opens up security problems and then say "well it's someone else's problem"
  457. # [15:47] <micheil> okay, fair point.
  458. # [15:48] <micheil> but I don't see it as something that requires a server-side change.
  459. # [15:50] <micheil> the websocket client is to expect back a valid http header structure, with a status code of 101, if it doesn't receive that, then it should close the connection
  460. # [15:50] <micheil> (iirc, the spec actually says something very similar to that.)
  461. # [15:52] <jgraham> That was more or less -75. And it was deem insufficiently secure
  462. # [15:52] <jgraham> *deemed
  463. # [15:53] <micheil> right
  464. # [15:59] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  465. # [16:26] * Joins: titacgs (~titacgs@201.250.167.101)
  466. # [16:28] * Joins: EclipseGc (~EclipseGc@ip68-12-160-21.ok.ok.cox.net)
  467. # [17:04] * Joins: bobchao (~cctw@112.105.140.77)
  468. # [17:06] * Quits: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com) (Remote host closed the connection)
  469. # [17:10] * Joins: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com)
  470. # [17:22] * Quits: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se) (Remote host closed the connection)
  471. # [17:24] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  472. # [17:33] * Joins: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net)
  473. # [18:06] * Quits: boblet (~boblet@p1201-ipbf709osakakita.osaka.ocn.ne.jp) (Quit: boblet)
  474. # [18:23] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 260 seconds)
  475. # [18:30] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  476. # [18:37] * Joins: eighty4 (~eighty4@c-76c8e455.012-403-6c6b701.cust.bredbandsbolaget.se)
  477. # [18:56] <hsivonen> Why is Web Socket still being discussed as if it were up for discussion? surely the window of opportunity for changing it is closing fast as multiple implementations are about to ship?
  478. # [19:19] <gsnedders> Because creating a spec that people agree on is more important than one browsers will implement?
  479. # [19:19] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  480. # [19:22] * Quits: estellevw (~estelle@adsl-76-254-4-20.dsl.pltn13.sbcglobal.net) (Quit: estellevw)
  481. # [19:35] * Quits: bobchao (~cctw@112.105.140.77) (Read error: Connection reset by peer)
  482. # [19:39] * Joins: bobchao (~cctw@112.105.140.77)
  483. # [19:40] <AryehGregor> Do screen readers treat <ins> and <u> (for instance) any differently?
  484. # [19:41] <jgraham> hsivonen: Yeah, I tend to agree
  485. # [19:41] <AryehGregor> Or <b> and <strong>, etc.?
  486. # [19:41] * AryehGregor needs to get a screen reader to test this kind of thing with.
  487. # [19:43] <jgraham> hsivonen: I think unless the current spec is shown to have substantial security problems the cost of change at this stage is likely to be prohibitive
  488. # [19:45] <jgraham> And I would prefer we had discussions on that basis rather than the basis of what would be better given a clean slate of implementations
  489. # [19:46] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 260 seconds)
  490. # [19:49] * Quits: bobchao (~cctw@112.105.140.77) (Quit: Leaving.)
  491. # [19:51] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  492. # [19:51] <Hixie> jgraham, hsivonen: if you think that, you shoudl tell the hybi list
  493. # [19:52] <jgraham> Hixie: Fair point
  494. # [19:56] <hsivonen> I'm not going to start participating on hybi
  495. # [19:57] <Hixie> btw have you noticed how traffic has dropped to zero again on that list?
  496. # [19:57] * Joins: erlehmann (~erlehmann@dslb-092-078-133-222.pools.arcor-ip.net)
  497. # [19:57] <Hixie> after i stopped posting?
  498. # [19:57] <Hixie> there is a direct correlation between the volume of traffic and my posting to the list
  499. # [19:58] <Hixie> i wonder if there is causation, or if i'm just affected by the same external factors as everyone else
  500. # [19:59] <hsivonen> I don't read hybi, so I don't have observational data
  501. # [19:59] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  502. # [20:01] <Philip`> Hixie: You should generate a random posting schedule, so that the days you post are not correlated to any outside influence
  503. # [20:01] <Hixie> i'm considering it
  504. # [20:03] <hsivonen> are there any plans to support Web Socket multiplexing over SPDY?
  505. # [20:07] * Joins: maikmerten_ (~maikmerte@port-92-201-163-14.dynamic.qsc.de)
  506. # [20:08] <Hixie> i hope not
  507. # [20:08] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  508. # [20:08] <Hixie> what would the point be?
  509. # [20:09] * Quits: maikmerten (~maikmerte@port-92-201-75-125.dynamic.qsc.de) (Ping timeout: 264 seconds)
  510. # [20:25] * Joins: ttepasse (~ttepasse@ip-109-90-160-217.unitymediagroup.de)
  511. # [20:26] * Joins: henrikbjorn (~hb@c83-249-67-192.bredband.comhem.se)
  512. # [20:28] * Joins: boogyman (~boogy@unaffiliated/boogyman)
  513. # [20:29] * Joins: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com)
  514. # [20:33] * Joins: miketaylr (~miketaylr@24.42.95.108)
  515. # [20:40] * Quits: titacgs (~titacgs@201.250.167.101) (Remote host closed the connection)
  516. # [20:45] * Joins: titacgs (~titacgs@201.250.167.101)
  517. # [20:47] * Joins: Smylers1 (~smylers@host86-163-18-105.range86-163.btcentralplus.com)
  518. # [20:49] * Quits: Smylers (~smylers@host86-183-56-219.range86-183.btcentralplus.com) (Ping timeout: 240 seconds)
  519. # [20:53] <hsivonen> Hixie: conserving kernel-level resources and using already-established TCP windows
  520. # [20:53] <hsivonen> Hixie: perhaps not a good optimization
  521. # [20:55] * Quits: kennyluck (~kennyluck@EM114-51-106-67.pool.e-mobile.ne.jp) (Ping timeout: 265 seconds)
  522. # [21:00] * Quits: miketaylr (~miketaylr@24.42.95.108) (Quit: miketaylr)
  523. # [21:01] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  524. # [21:01] * Joins: kennyluck (~kennyluck@EM114-51-20-73.pool.e-mobile.ne.jp)
  525. # [21:03] * Quits: workmad3 (~workmad3@cpc3-bagu10-0-0-cust651.1-3.cable.virginmedia.com) (Remote host closed the connection)
  526. # [21:07] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Ping timeout: 245 seconds)
  527. # [21:09] * Joins: miketaylr (~miketaylr@24.42.95.108)
  528. # [21:09] * Joins: boogyman (~boogy@unaffiliated/boogyman)
  529. # [21:12] * Joins: nessy (~Adium@124-168-158-57.dyn.iinet.net.au)
  530. # [21:12] * Joins: hamcore (rhythm@unaffiliated/msmosso)
  531. # [21:22] <Hixie> hsivonen: you can do multiplexing already using shared workers
  532. # [21:23] <hsivonen> Hixie: doesn't that require the JS layer to do the multiplexing?
  533. # [21:23] <Hixie> yes
  534. # [21:24] <hsivonen> if multiplexing is desirable, wouldn't it make sense to make the bowser manage it?
  535. # [21:24] <hsivonen> *browser
  536. # [21:24] <Hixie> the author has to manage it on the server-side anyway
  537. # [21:25] <Hixie> it's not clear that forcing a particular multiplexing scheme on the protocol is desireable
  538. # [21:25] <Hixie> TCP doesn't do multiplexing
  539. # [21:25] <gsnedders> But TCP is lower level anyway
  540. # [21:25] <Hixie> websockets is supposed to be TCP for browsers
  541. # [21:25] * gsnedders doesn't get the relvence there
  542. # [21:25] <Hixie> if it wasn't for security concerns, we'd just be using TCP
  543. # [21:25] <gsnedders> I thought websockets was built on TCP. Obviously I misunderstood.
  544. # [21:26] <gsnedders> (There again, when I last looked at the spec was, uh, years ago)
  545. # [21:26] <Hixie> websockets is the minimal amount on top of TCP to make TCP work for browsers
  546. # [21:38] * Quits: henrikbjorn (~hb@c83-249-67-192.bredband.comhem.se) (Remote host closed the connection)
  547. # [21:51] * Quits: maikmerten_ (~maikmerte@port-92-201-163-14.dynamic.qsc.de) (Remote host closed the connection)
  548. # [21:51] * Quits: boogyman (~boogy@unaffiliated/boogyman) (Quit: ChatZilla 0.9.86 [Firefox 3.6.8/20100722155716])
  549. # [21:56] * Joins: Smylers (~smylers@host86-184-37-108.range86-184.btcentralplus.com)
  550. # [21:58] * Quits: Smylers1 (~smylers@host86-163-18-105.range86-163.btcentralplus.com) (Ping timeout: 245 seconds)
  551. # [21:59] * Quits: Lachy (~Lachlan@cm-84.215.59.50.getinternet.no) (Quit: Leaving)
  552. # [21:59] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  553. # [22:06] * Joins: nimbupani (~nimbupani@c-24-22-131-46.hsd1.wa.comcast.net)
  554. # [22:06] * Quits: hamcore (rhythm@unaffiliated/msmosso)
  555. # [22:07] * Joins: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net)
  556. # [22:07] * Joins: aho (~nya@fuld-4d00d4fa.pool.mediaWays.net)
  557. # [22:10] * Joins: cying (~cying@c-24-4-120-70.hsd1.ca.comcast.net)
  558. # [22:16] * Joins: nickrathert (~nickrathe@c-67-175-44-226.hsd1.il.comcast.net)
  559. # [22:17] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 252 seconds)
  560. # [22:22] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  561. # [22:23] * Quits: nickrathert (~nickrathe@c-67-175-44-226.hsd1.il.comcast.net) (Quit: nickrathert)
  562. # [22:23] * Quits: weinig (~weinig@c-69-181-125-223.hsd1.ca.comcast.net) (Quit: weinig)
  563. # [22:31] * Quits: nessy (~Adium@124-168-158-57.dyn.iinet.net.au) (Quit: Leaving.)
  564. # [22:32] * Quits: Heimidal (~heimidal@unaffiliated/heimidal) (Remote host closed the connection)
  565. # [22:33] * Joins: ako (~nya@fuld-4d00d71b.pool.mediaWays.net)
  566. # [22:35] * Quits: aho (~nya@fuld-4d00d4fa.pool.mediaWays.net) (Ping timeout: 245 seconds)
  567. # [22:44] * Joins: annevk (~annevk@5355737B.cable.casema.nl)
  568. # [22:46] * Joins: paul_irish (~paul_iris@209.117.47.253)
  569. # [22:51] <annevk> what a backlog...
  570. # [22:52] <annevk> you'd think less would happen in a week in July on the interwebs
  571. # [22:53] <annevk> email not completely dealt with count went from its normal 700 to high 1800
  572. # [22:54] * Quits: ako (~nya@fuld-4d00d71b.pool.mediaWays.net) (Ping timeout: 245 seconds)
  573. # [22:56] <Hixie> heh
  574. # [22:57] * Quits: ROBOd (~robod@92.86.246.81) (Quit: .)
  575. # [23:01] <annevk> yay for abarth
  576. # [23:05] * Quits: gavin_ (~gavin@firefox/developer/gavin) (Ping timeout: 248 seconds)
  577. # [23:05] * Quits: miketaylr (~miketaylr@24.42.95.108) (Remote host closed the connection)
  578. # [23:06] * Joins: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net)
  579. # [23:06] * Quits: Heimidal (~heimidal@c-71-237-116-77.hsd1.co.comcast.net) (Changing host)
  580. # [23:06] * Joins: Heimidal (~heimidal@unaffiliated/heimidal)
  581. # [23:08] * Quits: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net) (Quit: 8403864 bytes have been tenured, next gc will be global.)
  582. # [23:08] * Joins: aho (~nya@fuld-4d00d0cb.pool.mediaWays.net)
  583. # [23:08] * Joins: estellevw (~estelle@adsl-76-254-4-20.dsl.pltn13.sbcglobal.net)
  584. # [23:09] <estellevw> In what cases, if any, would the :optional UI pseudo class match an element. :required matches form elements with the required attribute, which is boolean, so true if present
  585. # [23:09] <jgraham> annevk: Yeah, he should get a medal or something
  586. # [23:09] <estellevw> is it all form elements that don't have the attribute set?
  587. # [23:10] <hsivonen> annevk, jgraham: for general awesomeness or something in particular?
  588. # [23:10] * annevk just noticed the URL-spec thread
  589. # [23:10] <hsivonen> ah
  590. # [23:12] <estellevw> answered my own question - any form element that does not have the attribute of required
  591. # [23:13] <hsivonen> hmm. no new objection on the versioning poll
  592. # [23:15] * Joins: dbaron (~dbaron@c-98-234-51-190.hsd1.ca.comcast.net)
  593. # [23:16] <jgraham> hsivonen: We have a few more days though, right
  594. # [23:16] <jgraham> ?
  595. # [23:17] <jgraham> I will reply to that, but it takes more effort than the ascii one
  596. # [23:17] <hsivonen> jgraham: yeah, it'll be open for a few days, still
  597. # [23:24] <annevk> from Hixie on hybi "I apologise in advance if this causes a spike in traffic to the list."
  598. # [23:25] <annevk> and a spike it was, geez :)
  599. # [23:25] <annevk> 71 emails!
  600. # [23:26] <Hixie> only 71?
  601. # [23:26] * Joins: gavin_ (~gavin@firefox/developer/gavin)
  602. # [23:32] <annevk> well, in that particular thread
  603. # [23:32] * Joins: othermaciej (~mjs@c-69-181-42-237.hsd1.ca.comcast.net)
  604. # [23:39] * Quits: cardona507 (~cardona50@c-67-180-160-250.hsd1.ca.comcast.net) (Ping timeout: 240 seconds)
  605. # [23:44] * Joins: roc (~roc@203-97-204-82.dsl.clear.net.nz)
  606. # [23:46] <Hixie> annevk: oh in that comment i meant all the threads, not just that one
  607. # [23:46] <Hixie> but i didn't check the numbers
  608. # [23:47] <Hixie> 71 just sounds a bit low for what it felt like :-)
  609. # [23:50] * Quits: FastJack (~fastjack@dumpstr.net) (Ping timeout: 252 seconds)
  610. # [23:52] * Quits: paul_irish (~paul_iris@209.117.47.253) (Remote host closed the connection)
  611. # [23:55] <annevk> sounds like you get even more email than me if you are underwhelmed by 71 ;p
  612. # [23:57] * Quits: cying (~cying@c-24-4-120-70.hsd1.ca.comcast.net) (Quit: cying)
  613. # Session Close: Mon Jul 26 00:00:00 2010

The end :)