Prototype of chunked transfer encoded POST.

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/completion_callback.h"
 #include "net/base/upload_data.h"
 
 namespace net {
 
 class FileStream;
 class IOBuffer;
 
-class UploadDataStream {
+class UploadDataStream : public UploadData::ChunkCallback {
  public:
+  // Interface implemented by callers who require callbacks when new chunks
+  // of data are received.
+  class ChunkCallback {

[vandebo (ex-Chrome), 2011/01/14 05:53:44]

This interface class is the same as UploadData::ChunkCallback.  Is there a
reason to implement the same interface again?

[Satish, 2011/01/14 18:09:29]

Wan-Teh suggests I rename this to Delegate. I'm not comfortable with calling
this a Delegate when it is set by the caller only for chunked uploads. How about
I remove these and just use a Task* for the callback in both UploadData and
UploadDataStream? The Task* will be kept alive and invoked multiple times
throughout this object's lifetime.

+   public:
+    // Invoked when a new data chunk was given for a chunked transfer upload.
+    virtual void OnChunkAvailable() = 0;
+
+   protected:
+    virtual ~ChunkCallback() {}
+  };
+
   // 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);
 
   ~UploadDataStream();
 
   // Returns the stream's buffer and buffer length.
   IOBuffer* buf() const { return buf_; }
   size_t buf_len() const { return buf_len_; }
 
   // 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 DidConsume(size_t num_bytes);
 
+  // Sets the callback to be invoked when new data is available to upload.
+  // The callback is invoked only once and needs to be set again if the caller
+  // needs to be indicated again in future.
+  void set_chunk_callback(ChunkCallback* callback);
+
   // Returns the total size of the data stream and the current position.
   // size() is not to be used to determine whether the stream has ended
   // because it is possible for the stream to end before its size is reached,
   // for example, if the file is truncated.
   uint64 size() const { return total_size_; }
   uint64 position() const { return current_position_; }
 
+  bool is_chunked() const { return data_->is_chunked(); }
+
   // Returns whether there is no more data to read, regardless of whether
   // position < size.
   bool eof() const { return eof_; }
 
+  // UploadData::ChunkCallback members.
+
+  // Callback invoked by UploadData when new data is available.
+  void OnChunkAvailable();
+
  private:
   // Protects from public access since now we have a static creator function
   // which will do both creation and initialization and might return an error.
   explicit UploadDataStream(UploadData* data);
 
   // Fills the buffer with any remaining data and sets eof_ if there was nothing
   // left to fill the buffer with.
   // Returns OK if the operation succeeds. Otherwise error code is returned.
   int FillBuf();
 
   UploadData* data_;
 
   // This buffer is filled with data to be uploaded.  The data to be sent is
   // always at the front of the buffer.  If we cannot send all of the buffer at
   // once, then we memmove the remaining portion and back-fill the buffer for
   // the next "write" call.  buf_len_ indicates how much data is in the buffer.
   enum { kBufSize = 16384 };
   scoped_refptr<IOBuffer> buf_;
   size_t buf_len_;
 
-  // Iterator to the upload element to be written to the send buffer next.
-  std::vector<UploadData::Element>::iterator next_element_;
+  // Index of the upload element to be written to the send buffer next.
+  size_t next_element_;

[wtc, 2011/01/14 03:09:31]

Why does next_element_ need to be an array index?  Is it
because you need it to stay valid after reaching the end of
array?  (In contrast, an iterator becomes end() and can't be
incremented any more.)

[Satish, 2011/01/14 18:09:29]

Yes

 
   // The byte offset into next_element_'s data buffer if the next element is
   // a TYPE_BYTES element.
   size_t next_element_offset_;
 
   // A stream to the currently open file, for next_element_ if the next element
   // is a TYPE_FILE element.
   scoped_ptr<FileStream> next_element_stream_;
 
   // The number of bytes remaining to be read from the currently open file
   // if the next element is of TYPE_FILE.
   uint64 next_element_remaining_;
 
   // Size and current read position within the stream.
   uint64 total_size_;
   uint64 current_position_;
 
+  // Whether we have run out of data and waiting for more to come in.
+  bool waiting_for_data_;
+
+  // Callback to be invoked by us when new data is available.
+  ChunkCallback* chunk_callback_;
+
   // Whether there is no data left to read.
   bool eof_;
 
   DISALLOW_COPY_AND_ASSIGN(UploadDataStream);
 };
 
 }  // namespace net
 
 #endif  // NET_BASE_UPLOAD_DATA_STREAM_H_