Introduce ParallelDownloadJob.

content/browser/download/download_job.cc

Index: content/browser/download/download_job.cc
diff --git a/content/browser/download/download_job.cc b/content/browser/download/download_job.cc
index c54428d12999ce2c9caf9ae6372939a741f6c648..5de2ef605b4e1271926d08bbcad7c04c84b9dd52 100644
--- a/content/browser/download/download_job.cc
+++ b/content/browser/download/download_job.cc
@@ -4,40 +4,20 @@
 
 #include "content/browser/download/download_job.h"
 
-namespace content {
-
-// Unknown download progress.
-const int kDownloadProgressUnknown = -1;
+#include "content/browser/download/download_item_impl.h"
 
-// Unknown download speed.
-const int kDownloadSpeedUnknown = -1;
+namespace content {
 
-DownloadJob::DownloadJob() : manager_(nullptr) {}
+DownloadJob::DownloadJob() : download_item_(nullptr) {}
 
 DownloadJob::~DownloadJob() = default;
 
-void DownloadJob::OnAttached(DownloadJob::Manager* manager) {
-  DCHECK(!manager_) << "DownloadJob::Manager has already been attached.";
-  manager_ = manager;
-}
-
-void DownloadJob::OnBeforeDetach() {
-  manager_ = nullptr;
-}
-
-void DownloadJob::StartedSavingResponse() {
-  if (manager_)
-    manager_->OnSavingStarted(this);
-}
-
-void DownloadJob::Interrupt(DownloadInterruptReason reason) {
-  if (manager_)
-    manager_->OnDownloadInterrupted(this, reason);
+void DownloadJob::Attach(DownloadItemImpl* download_item) {
+  download_item_ = download_item;
 }
 
-void DownloadJob::Complete() {
-  if (manager_)
-    manager_->OnDownloadComplete(this);
+void DownloadJob::InitializeDownloadFile() const {
+  download_item_->InitializeDownloadFile();

[asanka, 2017/02/16 16:27:39]

It would be great if we could have calls going one way. I.e. does it make sense
for DownloadItemImpl to retain ownership of the DownloadFile? Or should
DownloadJob be the owner of the DownloadFile.

DownloadFile is only supposed to contain state for an active download, which
maps to the lifetime of a Job.

[xingliu, 2017/02/20 18:59:10]

Ideally the file should live with DownloadJob subclass, can we do it in a
separate CL, since this will involve a lot of refactoring.

Also I'm fine with adding the parallel logic in DownloadItemImpl, maybe adding
all these DownloadJob classes are over abstraction for parallel download, wdyt?

 }
 
 }  // namespace content