WebSocketFrameChunk should use IOBuffer to hold data

net/websockets/websocket_frame.h

Index: net/websockets/websocket_frame.h
diff --git a/net/websockets/websocket_frame.h b/net/websockets/websocket_frame.h
index bce6fa22dbf4097f8e17b52ee9544749ab19f233..057c017831926d6d1235097293263aa2f2eb1ae4 100644
--- a/net/websockets/websocket_frame.h
+++ b/net/websockets/websocket_frame.h
@@ -8,11 +8,14 @@
 #include <vector>
 
 #include "base/basictypes.h"
+#include "base/memory/ref_counted.h"
 #include "base/memory/scoped_ptr.h"
 #include "net/base/net_export.h"
 
 namespace net {
 
+class IOBuffer;
+
 // Represents a WebSocket frame header.
 //
 // Members of this class correspond to each element in WebSocket frame header
@@ -74,7 +77,10 @@ struct NET_EXPORT_PRIVATE WebSocketFrameChunk {
   bool final_chunk;
 
   // |data| is always unmasked even if the frame is masked.
-  std::vector<char> data;
+  scoped_refptr<IOBuffer> data;
+
+  // |size| represents size of |data| in bytes.
+  uint64_t size;

[mmenke, 2012/07/26 14:44:45]

Do we really need a 64-bit unsigned integer for size?  My feeling is that unless
we're actually going to support chunks that large, and plumb the support all the
way through, then we should use use ints.  Makes it much clearer that we don't
actually support huge chunks, and the limits the code should check for.

Our socket classes don't support either reads or writes greater than MAX_INT,
anyways, so we'd either have to handle breaking up a huge number into ints when
sending it (A waste of time, easy to get wrong, and something we're not going to
have unit tests for), or explicitly not support numbers that large further down
the pipe, anyways.

May just want to use IOBufferWithSize.

[Yuta Kitamura, 2012/07/27 08:01:08]

Agreed, at least |size| should be an int.

I think the trade off between IOBuffer+int and IOBufferWithSize here is:
- With IOBuffer+int we can use any subclass of IOBuffer for |data|.
- With IOBufferWithSize we should always use IOBufferWithSize.

I don't think of any use case that requires the flexibility of the former, so
IOBufferWithSize would be just fine.

[Takashi Toyoshima, 2012/07/27 10:28:43]

This payload data represents a object in JavaScript, and it's impossible to
handle a large object which size is over 32-bit. So, I agreed to use
IOBufferWithSize here.

 };
 
 // Contains four-byte data representing "masking key" of WebSocket frames.