Add chunked uploads support to SPDY

net/base/upload_data_stream.h

 // Copyright (c) 2010 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef NET_BASE_UPLOAD_DATA_STREAM_H_
 #define NET_BASE_UPLOAD_DATA_STREAM_H_
 #pragma once
 
 #include "base/scoped_ptr.h"
 #include "net/base/upload_data.h"
 
 namespace net {
 
 class FileStream;
 class IOBuffer;
 
 class UploadDataStream {
  public:
   ~UploadDataStream();
 
   // Returns a new instance of UploadDataStream if it can be created and
   // initialized successfully. If not, NULL will be returned and the error
   // code will be set if the output parameter error_code is not empty.
   static UploadDataStream* Create(UploadData* data, int* error_code);
 
   // Returns the stream's buffer and buffer length.
   IOBuffer* buf() const { return buf_; }
   size_t buf_len() const { return buf_len_; }
+  size_t GetMaxBufferSize() const { return kBufSize; }

[willchan no longer on Chromium, 2011/02/01 23:35:59]

It's annoying we have to expose this. We should just be returning a
IOBufferWithSize for the consumer to take. Or write to a buffer that they
provide.

Please leave a TODO to fix this, so people will know not to use this.

[Satish, 2011/02/22 14:25:44]

We don't write to a buffer provided by the caller, but the caller indeed copies
the data to their own IOBuffer. To do that the caller needs to know how large
the IOBuffer should be allocated for, hence this method. The alternative is to
pass this constant as a parameter at creation time which looks uglier because
the consumer and creator of this object are different classes. Since this is
primarily used to avoid unwanted allocations and just use the same IOBuffer in
http_stream_parser, I'm not sure why you feel this is ugly. A caller who sends
the IOBuffer as a whole doesn't care about this method at all.

[willchan no longer on Chromium, 2011/02/24 19:03:39]

I was thinking that instead of an interface like MarkConsumedAndFillBuffer(),
we'd have something like a int Read(num_bytes, buf, callback) member function.
The user provides a IOBuffer with the appropriate max size specified by
"num_bytes". The return value indicates the size that was populated by
UploadDataStream.

A MarkConsumedAndFillBuffer() member function dictates that UploadDataStream
owns the IOBuffer, which is just lent out to the caller to read temporarily.
This means that when MarkConsumedAndFillBuffer() is called, UploadDataStream has
to do a memmove. Ew, why?

Users should provide their own buffer. They can either use new buffers and keep
calling Read() to populate the new buffers, or they can finishing using their
first buffer and then pass that same buffer to Read(). Why does UploadDataStream
dictate the Read() size? Shouldn't callers be in control of how much data they
want to read at a time?

 
   // Call to indicate that a portion of the stream's buffer was consumed.  This
   // call modifies the stream's buffer so that it contains the next segment of
   // the upload data to be consumed.
   void MarkConsumedAndFillBuffer(size_t num_bytes);
 
   // Sets the callback to be invoked when new chunks are available to upload.
   void set_chunk_callback(ChunkCallback* callback) {
     data_->set_chunk_callback(callback);
   }
@@ skipping 53 matching lines @@
 
   // Whether there is no data left to read.
   bool eof_;
 
   DISALLOW_COPY_AND_ASSIGN(UploadDataStream);
 };
 
 }  // namespace net
 
 #endif  // NET_BASE_UPLOAD_DATA_STREAM_H_