[giow] (0) Make WebSocket.binaryType more like XHR.responseType

git-svn-id: http://svn.whatwg.org/webapps@6158 340c8d12-0b0e-0410-8428-c7bf67bfef74

complete.html

@@ -78882,7 +78882,7 @@ <h4 id=the-websocket-interface><span class=secno>11.3.2 </span>The <code><a href
 
   // messaging
            attribute <a href=#function>Function</a> <a href=#handler-websocket-onmessage title=handler-WebSocket-onmessage>onmessage</a>;
-           attribute object <a href=#dom-websocket-binarytype title=dom-WebSocket-binaryType>binaryType</a>;
+           attribute DOMString <a href=#dom-websocket-binarytype title=dom-WebSocket-binaryType>binaryType</a>;
   void <a href=#dom-websocket-send title=dom-WebSocket-send>send</a>(in DOMString data);
   void <a href=#dom-websocket-send title=dom-WebSocket-send>send</a>(in <span>ArrayBuffer</span> data);
   void <a href=#dom-websocket-send title=dom-WebSocket-send>send</a>(in <a href=#blob>Blob</a> data);
@@ -79142,31 +79142,28 @@ <h4 id=the-websocket-interface><span class=secno>11.3.2 </span>The <code><a href
   </div>
 
   <hr><p>When a <code><a href=#websocket>WebSocket</a></code> object is created, its <dfn id=dom-websocket-binarytype title=dom-WebSocket-binaryType><code>binaryType</code></dfn> IDL
-  attribute must be set to the <code><a href=#blob>Blob</a></code> interface object
-  associated with the same global object as the <code title=dom-WebSocket><a href=#dom-websocket>WebSocket</a></code> constructor used to create
-  the <code><a href=#websocket>WebSocket</a></code> object. On getting, it must return the
-  last value it was set to. On setting, if the new value is either the
-  <code><a href=#blob>Blob</a></code> or <code>ArrayBuffer</code> interface object
-  associated with the same global object as the <code title=dom-WebSocket><a href=#dom-websocket>WebSocket</a></code> constructor used to create
-  the <code><a href=#websocket>WebSocket</a></code> object, then set the IDL attribute to
-  this new value. Otherwise, throw a <code><a href=#not_supported_err>NOT_SUPPORTED_ERR</a></code>
-  exception.</p>
+  attribute must be set to the string "<code title="">blob</code>". On
+  getting, it must return the last value it was set to. On setting, if
+  the new value is either the string "<code title="">blob</code>" or
+  the string "<code title="">arraybuffer</code>", then set the IDL
+  attribute to this new value. Otherwise, throw a
+  <code><a href=#syntax_err>SYNTAX_ERR</a></code> exception.</p>
 
   <p class=note>This attribute allows authors to control how binary
-  data is exposed to scripts. By setting the attribute to
-  <code><a href=#blob>Blob</a></code>, binary data is returned in <code><a href=#blob>Blob</a></code>
-  form; by setting it to <code>ArrayBuffer</code>, it is returned in
-  <code>ArrayBuffer</code> form. User agents can use this as a hint
-  for how to handle incoming binary data: if the attribute is set to
-  <code><a href=#blob>Blob</a></code>, it is safe to spool it to disk, and if it is set
-  to <code>ArrayBuffer</code>, it is likely more efficient to keep the
-  data in memory. Naturally, user agents are encouraged to use more
-  subtle heuristics to decide whether to keep incoming data in memory
-  or not, e.g. based on how big the data is or how common it is for a
-  script to change the attribute at the last minute. This latter
-  aspect is important in particular because it is quite possible for
-  the attribute to be changed after the user agent has received the
-  data but before the user agent as fired the event for it.</p>
+  data is exposed to scripts. By setting the attribute to "<code title="">blob</code>", binary data is returned in <code><a href=#blob>Blob</a></code>
+  form; by setting it to "<code title="">arraybuffer</code>", it is
+  returned in <code>ArrayBuffer</code> form. User agents can use this
+  as a hint for how to handle incoming binary data: if the attribute
+  is set to "<code title="">blob</code>", it is safe to spool it to
+  disk, and if it is set to "<code title="">arraybuffer</code>", it is
+  likely more efficient to keep the data in memory. Naturally, user
+  agents are encouraged to use more subtle heuristics to decide
+  whether to keep incoming data in memory or not, e.g. based on how
+  big the data is or how common it is for a script to change the
+  attribute at the last minute. This latter aspect is important in
+  particular because it is quite possible for the attribute to be
+  changed after the user agent has received the data but before the
+  user agent as fired the event for it.</p>
 
   <p>The <dfn id=dom-websocket-send title=dom-WebSocket-send><code>send(<var title="">data</var>)</code></dfn> method transmits data using the
   connection. If the <code title=dom-WebSocket-readyState><a href=#dom-websocket-readystate>readyState</a></code> attribute is
@@ -79294,14 +79291,13 @@ <h4 id=the-websocket-interface><span class=secno>11.3.2 </span>The <code><a href
 
     <p>If <var title="">type</var> indicates that the data is Binary,
     and <code title=dom-WebSocket-binaryType><a href=#dom-websocket-binarytype>binaryType</a></code> is
-    set to <code><a href=#blob>Blob</a></code>, then set <var title="">event</var>'s
-    <code title=dom-MessageEvent-data><a href=#dom-messageevent-data>data</a></code> attribute to a new
+    set to "<code title="">blob</code>", then set <var title="">event</var>'s <code title=dom-MessageEvent-data><a href=#dom-messageevent-data>data</a></code> attribute to a new
     <code><a href=#blob>Blob</a></code> object that represents <var title="">data</var>
     as its raw data. <a href=#refsFILEAPI>[FILEAPI]</a></p>
 
     <p>If <var title="">type</var> indicates that the data is Binary,
     and <code title=dom-WebSocket-binaryType><a href=#dom-websocket-binarytype>binaryType</a></code> is
-    set to <code>ArrayBuffer</code>, then set <var title="">event</var>'s <code title=dom-MessageEvent-data><a href=#dom-messageevent-data>data</a></code> attribute to a new
+    set to "<code title="">arraybuffer</code>", then set <var title="">event</var>'s <code title=dom-MessageEvent-data><a href=#dom-messageevent-data>data</a></code> attribute to a new
     read-only <code>ArrayBuffer</code> object whose contents are <var title="">data</var>. <a href=#refsTYPEDARRAY>[TYPEDARRAY]</a></p>
 
    </li>
@@ -79317,12 +79313,11 @@ <h4 id=the-websocket-interface><span class=secno>11.3.2 </span>The <code><a href
   perform the above steps efficiently before they run the task,
   picking tasks from other <a href=#task-queue title="task queue">task queues</a>
   while they prepare the buffers if not. For example, if the <code title=dom-WebSocket-binaryType><a href=#dom-websocket-binarytype>binaryType</a></code> attribute was set
-  to <code><a href=#blob>Blob</a></code> when the data arrived, and the user agent
-  spooled all the data to disk, but just before running the above
-  <a href=#concept-task title=concept-task>task</a> for this particular message
-  the script switched <code title=dom-WebSocket-binaryType><a href=#dom-websocket-binarytype>binaryType</a></code> to
-  <code>ArrayBuffer</code>, the user agent would want to page the data
-  back to RAM before running this <a href=#concept-task title=concept-task>task</a> so as to avoid stalling the main
+  to "<code title="">blob</code>" when the data arrived, and the user
+  agent spooled all the data to disk, but just before running the
+  above <a href=#concept-task title=concept-task>task</a> for this particular
+  message the script switched <code title=dom-WebSocket-binaryType><a href=#dom-websocket-binarytype>binaryType</a></code> to "<code title="">arraybuffer</code>", the user agent would want to page the
+  data back to RAM before running this <a href=#concept-task title=concept-task>task</a> so as to avoid stalling the main
   thread while it created the <code>ArrayBuffer</code> object.</p>
 
   <hr><!--

source

@@ -89532,7 +89532,7 @@ interface <dfn>WebSocket</dfn> {
 
   // messaging
            attribute <span>Function</span> <span title="handler-WebSocket-onmessage">onmessage</span>;
-           attribute object <span title="dom-WebSocket-binaryType">binaryType</span>;
+           attribute DOMString <span title="dom-WebSocket-binaryType">binaryType</span>;
   void <span title="dom-WebSocket-send">send</span>(in DOMString data);
   void <span title="dom-WebSocket-send">send</span>(in <span>ArrayBuffer</span> data);
   void <span title="dom-WebSocket-send">send</span>(in <span>Blob</span> data);
@@ -89853,33 +89853,29 @@ socket.onopen = function () {
 
   <p>When a <code>WebSocket</code> object is created, its <dfn
   title="dom-WebSocket-binaryType"><code>binaryType</code></dfn> IDL
-  attribute must be set to the <code>Blob</code> interface object
-  associated with the same global object as the <code
-  title="dom-WebSocket">WebSocket</code> constructor used to create
-  the <code>WebSocket</code> object. On getting, it must return the
-  last value it was set to. On setting, if the new value is either the
-  <code>Blob</code> or <code>ArrayBuffer</code> interface object
-  associated with the same global object as the <code
-  title="dom-WebSocket">WebSocket</code> constructor used to create
-  the <code>WebSocket</code> object, then set the IDL attribute to
-  this new value. Otherwise, throw a <code>NOT_SUPPORTED_ERR</code>
-  exception.</p>
+  attribute must be set to the string "<code title="">blob</code>". On
+  getting, it must return the last value it was set to. On setting, if
+  the new value is either the string "<code title="">blob</code>" or
+  the string "<code title="">arraybuffer</code>", then set the IDL
+  attribute to this new value. Otherwise, throw a
+  <code>SYNTAX_ERR</code> exception.</p>
 
   <p class="note">This attribute allows authors to control how binary
-  data is exposed to scripts. By setting the attribute to
-  <code>Blob</code>, binary data is returned in <code>Blob</code>
-  form; by setting it to <code>ArrayBuffer</code>, it is returned in
-  <code>ArrayBuffer</code> form. User agents can use this as a hint
-  for how to handle incoming binary data: if the attribute is set to
-  <code>Blob</code>, it is safe to spool it to disk, and if it is set
-  to <code>ArrayBuffer</code>, it is likely more efficient to keep the
-  data in memory. Naturally, user agents are encouraged to use more
-  subtle heuristics to decide whether to keep incoming data in memory
-  or not, e.g. based on how big the data is or how common it is for a
-  script to change the attribute at the last minute. This latter
-  aspect is important in particular because it is quite possible for
-  the attribute to be changed after the user agent has received the
-  data but before the user agent as fired the event for it.</p>
+  data is exposed to scripts. By setting the attribute to "<code
+  title="">blob</code>", binary data is returned in <code>Blob</code>
+  form; by setting it to "<code title="">arraybuffer</code>", it is
+  returned in <code>ArrayBuffer</code> form. User agents can use this
+  as a hint for how to handle incoming binary data: if the attribute
+  is set to "<code title="">blob</code>", it is safe to spool it to
+  disk, and if it is set to "<code title="">arraybuffer</code>", it is
+  likely more efficient to keep the data in memory. Naturally, user
+  agents are encouraged to use more subtle heuristics to decide
+  whether to keep incoming data in memory or not, e.g. based on how
+  big the data is or how common it is for a script to change the
+  attribute at the last minute. This latter aspect is important in
+  particular because it is quite possible for the attribute to be
+  changed after the user agent has received the data but before the
+  user agent as fired the event for it.</p>
 
   <p>The <dfn title="dom-WebSocket-send"><code>send(<var
   title="">data</var>)</code></dfn> method transmits data using the
@@ -90054,14 +90050,15 @@ socket.onopen = function () {
 
     <p>If <var title="">type</var> indicates that the data is Binary,
     and <code title="dom-WebSocket-binaryType">binaryType</code> is
-    set to <code>Blob</code>, then set <var title="">event</var>'s
-    <code title="dom-MessageEvent-data">data</code> attribute to a new
+    set to "<code title="">blob</code>", then set <var
+    title="">event</var>'s <code
+    title="dom-MessageEvent-data">data</code> attribute to a new
     <code>Blob</code> object that represents <var title="">data</var>
     as its raw data. <a href="#refsFILEAPI">[FILEAPI]</a></p>
 
     <p>If <var title="">type</var> indicates that the data is Binary,
     and <code title="dom-WebSocket-binaryType">binaryType</code> is
-    set to <code>ArrayBuffer</code>, then set <var
+    set to "<code title="">arraybuffer</code>", then set <var
     title="">event</var>'s <code
     title="dom-MessageEvent-data">data</code> attribute to a new
     read-only <code>ArrayBuffer</code> object whose contents are <var
@@ -90084,13 +90081,13 @@ socket.onopen = function () {
   picking tasks from other <span title="task queue">task queues</span>
   while they prepare the buffers if not. For example, if the <code
   title="dom-WebSocket-binaryType">binaryType</code> attribute was set
-  to <code>Blob</code> when the data arrived, and the user agent
-  spooled all the data to disk, but just before running the above
-  <span title="concept-task">task</span> for this particular message
-  the script switched <code
-  title="dom-WebSocket-binaryType">binaryType</code> to
-  <code>ArrayBuffer</code>, the user agent would want to page the data
-  back to RAM before running this <span
+  to "<code title="">blob</code>" when the data arrived, and the user
+  agent spooled all the data to disk, but just before running the
+  above <span title="concept-task">task</span> for this particular
+  message the script switched <code
+  title="dom-WebSocket-binaryType">binaryType</code> to "<code
+  title="">arraybuffer</code>", the user agent would want to page the
+  data back to RAM before running this <span
   title="concept-task">task</span> so as to avoid stalling the main
   thread while it created the <code>ArrayBuffer</code> object.</p>