/lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-September/022674.html

https://github.com/whatwg/whatwg.org · HTML · 270 lines · 88 code · 175 blank · 7 comment · 0 complexity · 7baf00cfa220c4b6593164b03c25f981 MD5 · raw file 

    

  1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
    2. 

  2. <HTML>
    3. 

  3.  <HEAD>
    4. 

  4.    <TITLE> [whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket, transfer protocol)
    5. 

  5.    </TITLE>
    6. 

  6.    <LINK REL="Index" HREF="index.html" >
    7. 

  7.    <LINK REL="made" HREF="mailto:whatwg%40lists.whatwg.org?Subject=Re%3A%20%5Bwhatwg%5D%20Feature%20requests%20in%20WebSocket%20%28Was%3A%20BWTP%20for%20WebSocket%2C%0A%20transfer%20protocol%29&In-Reply-To=%3C4AA0CAF7.60706%40mortbay.com%3E">
    8. 

  8.    <META NAME="robots" CONTENT="index,nofollow">
    9. 

  9.    <META http-equiv="Content-Type" content="text/html; charset=us-ascii">
    10. 

  10.    <LINK REL="Previous"  HREF="022801.html">
    11. 

  11.    <LINK REL="Next"  HREF="023061.html">
    12. 

  12.  </HEAD>
    13. 

  13.  <BODY BGCOLOR="#ffffff">
    14. 

  14.    <H1>[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket, transfer protocol)</H1>
    15. 

  15. <!--htdig_noindex-->
    16. 

  16.     <B>Greg Wilkins</B> 
    17. 

  17.     <A HREF="mailto:whatwg%40lists.whatwg.org?Subject=Re%3A%20%5Bwhatwg%5D%20Feature%20requests%20in%20WebSocket%20%28Was%3A%20BWTP%20for%20WebSocket%2C%0A%20transfer%20protocol%29&In-Reply-To=%3C4AA0CAF7.60706%40mortbay.com%3E"
    18. 

  18.        TITLE="[whatwg] Feature requests in WebSocket (Was: BWTP for WebSocket, transfer protocol)">gregw at mortbay.com
    19. 

  19.        </A><BR>
    20. 

  20.     <I>Fri Sep  4 01:08:23 PDT 2009</I>
    21. 

  21.     <P><UL>
    22. 

  22.         <LI>Previous message: <A HREF="022801.html">[whatwg] RFC: Alternatives to storage mutex for cookies and	localStorage
    23. 

  23. </A></li>
    24. 

  24.         <LI>Next message: <A HREF="023061.html">[whatwg] Feature requests in WebSocket
    25. 

  25. </A></li>
    26. 

  26.          <LI> <B>Messages sorted by:</B> 
    27. 

  27.               <a href="date.html#22674">[ date ]</a>
    28. 

  28.               <a href="thread.html#22674">[ thread ]</a>
    29. 

  29.               <a href="subject.html#22674">[ subject ]</a>
    30. 

  30.               <a href="author.html#22674">[ author ]</a>
    31. 

  31.          </LI>
    32. 

  32.        </UL>
    33. 

  33.     <HR>  
    34. 

  34. <!--/htdig_noindex-->
    35. 

  35. <!--beginarticle-->
    36. 

  36. <PRE>
    37. 

  37. Ian Hickson wrote:
    38. 

  38. &gt;<i> On Fri, 14 Aug 2009, Jeremy Orlow wrote:
    39. 

  39. </I>&gt;&gt;<i> &gt; On Fri, Aug 14, 2009 at 3:45 AM, Ian Hickson &lt;<A HREF="http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org">ian at hixie.ch</A>&gt; wrote:
    40. 

  40. </I>&gt;&gt;&gt;<i> &gt; &gt; On Fri, 7 Aug 2009, Jonas Sicking wrote:
    41. 

  41. </I>&gt;&gt;&gt;<i> &gt; &gt; What would the API look like?
    42. 

  42. </I>&gt;&gt;<i> &gt; 
    43. 

  43. </I>&gt;&gt;<i> &gt; It seems like it could be done transparently to the web developer.  If 
    44. 

  44. </I>&gt;&gt;<i> &gt; you open 2 sockets to the same server, the UA could just open another 
    45. 

  45. </I>&gt;&gt;<i> &gt; &quot;channel&quot; on the same connection.
    46. 

  46. </I>&gt;<i> 
    47. 

  47. </I>&gt;<i> That would force the complexity on the server-side developer, which I 
    48. 

  48. </I>&gt;<i> don't think we would want to do.
    49. 

  49. </I>
    50. 

  50. The server on the server-side could hide the details from the
    51. 

  51. server side developer.
    52. 

  52. 

  53. With HTTP, the server side developer handles requests and has
    54. 

  54. little idea what connection they came over.  Frequently requests
    55. 

  55. from multiple connections are multiplexed onto a single connection
    56. 

  56. by proxies, netscalers or similar.   Server side developers
    57. 

  57. do not have to deal with this.   Developers of the server do.
    58. 

  58. 

  59. 

  60. &gt;&gt;&gt;<i> &gt; &gt; What would the wire level look like?
    61. 

  61. </I>&gt;&gt;<i> &gt; 
    62. 

  62. </I>&gt;&gt;<i> &gt; It could be as simple as this: An extra byte or two at the beginning of 
    63. 

  63. </I>&gt;&gt;<i> &gt; every message that says which &quot;channel&quot; is transmitting.  A way to send 
    64. 

  64. </I>&gt;&gt;<i> &gt; control messages, two of which would be used to open and close channels.
    65. 

  65. </I>&gt;<i> 
    66. 

  66. </I>&gt;<i> I don't understand why we'd do that rather than just use two TCP 
    67. 

  67. </I>&gt;<i> connections.
    68. 

  68. </I>
    69. 

  69. Because TCP connections are not free.   Resources are often
    70. 

  70. allocated server side per connection.  As a server side developer,
    71. 

  71. I would much rather have a little more parsing to do on fewer connections
    72. 

  72. than less parsing on many more connections.
    73. 

  73. 

  74. Browsers safely multiple plex requests from multiple windows
    75. 

  75. and tabs onto shared connections for HTTP, I don't see why that
    76. 

  76. would be a problem for a new protocol.
    77. 

  77. 

  78. 

  79. regards
    80. 

  80. </PRE>
    81. 

  81. 

  82. 

  83. 

  84. 

  85. 

  86. 

  87. 

  88. 

  89. 

  90. 

  91. 

  92. 

  93. 

  94. 

  95. 

  96. 

  97. 

  98. 

  99. 

  100. 

  101. 

  102. 

  103. 

  104. 

  105. 

  106. 

  107. 

  108. 

  109. 

  110. 

  111. 

  112. 

  113. 

  114. 

  115. 

  116. 

  117. 

  118. 

  119. 

  120. 

  121. 

  122. 

  123. 

  124. 

  125. 

  126. 

  127. 

  128. 

  129. 

  130. 

  131. 

  132. 

  133. 

  134. 

  135. 

  136. 

  137. 

  138. 

  139. 

  140. 

  141. 

  142. 

  143. 

  144. 

  145. 

  146. 

  147. 

  148. 

  149. 

  150. 

  151. 

  152. 

  153. 

  154. 

  155. 

  156. 

  157. 

  158. 

  159. 

  160. 

  161. 

  162. 

  163. 

  164. 

  165. 

  166. 

  167. 

  168. 

  169. 

  170. 

  171. 

  172. 

  173. 

  174. 

  175. 

  176. 

  177. 

  178. 

  179. 

  180. 

  181. 

  182. 

  183. 

  184. 

  185. 

  186. 

  187. 

  188. 

  189. 

  190. 

  191. 

  192. 

  193. 

  194. 

  195. 

  196. 

  197. 

  198. 

  199. 

  200. 

  201. 

  202. 

  203. 

  204. 

  205. 

  206. 

  207. 

  208. 

  209. 

  210. 

  211. 

  212. 

  213. 

  214. 

  215. 

  216. 

  217. 

  218. 

  219. 

  220. 

  221. 

  222. 

  223. 

  224. 

  225. 

  226. 

  227. 

  228. 

  229. 

  230. 

  231. 

  232. 

  233. 

  234. 

  235. 

  236. 

  237. 

  238. 

  239. 

  240. 

  241. 

  242. 

  243. 

  244. 

  245. 

  246. 

  247. 

  248. 

  249. <!--endarticle-->
    250. 

  250. <!--htdig_noindex-->
    251. 

  251.     <HR>
    252. 

  252.     <P><UL>
    253. 

  253.         <!--threads-->
    254. 

  254. 	<LI>Previous message: <A HREF="022801.html">[whatwg] RFC: Alternatives to storage mutex for cookies and	localStorage
    255. 

  255. </A></li>
    256. 

  256. 	<LI>Next message: <A HREF="023061.html">[whatwg] Feature requests in WebSocket
    257. 

  257. </A></li>
    258. 

  258.          <LI> <B>Messages sorted by:</B> 
    259. 

  259.               <a href="date.html#22674">[ date ]</a>
    260. 

  260.               <a href="thread.html#22674">[ thread ]</a>
    261. 

  261.               <a href="subject.html#22674">[ subject ]</a>
    262. 

  262.               <a href="author.html#22674">[ author ]</a>
    263. 

  263.          </LI>
    264. 

  264.        </UL>
    265. 

  265. 

  266. <hr>
    267. 

  267. <a href="http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org">More information about the whatwg
    268. 

  268. mailing list</a><br>
    269. 

  269. <!--/htdig_noindex-->
    270. 

  270. </body></html>
    271.