Initial checkin of OfflineContentProvider.

components/offline_content/core/offline_item.h

Index: components/offline_content/core/offline_item.h
diff --git a/components/offline_content/core/offline_item.h b/components/offline_content/core/offline_item.h
new file mode 100644
index 0000000000000000000000000000000000000000..8ff8cb624ede7b5b9071c0157e6fa18dbd2aae53
--- /dev/null
+++ b/components/offline_content/core/offline_item.h
@@ -0,0 +1,134 @@
+// Copyright 2017 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 COMPONENTS_OFFLINE_CONTENT_CORE_OFFLINE_ITEM_H_
+#define COMPONENTS_OFFLINE_CONTENT_CORE_OFFLINE_ITEM_H_
+
+#include <string>
+
+#include "base/time/time.h"
+#include "components/offline_content/core/offline_item_file_extension.h"
+#include "components/offline_content/core/offline_item_filter.h"
+#include "components/offline_content/core/offline_item_state.h"
+#include "url/gurl.h"
+
+namespace offline_content {
+
+// An id that uniquely represents a piece of offline content.
+struct ContentId {
+ public:
+  // The namespace for the offline content.  This will be used to associate this
+  // id with a particular OfflineContentProvider.
+  std::string name_space;
+
+  // The id of the offline item.
+  std::string guid;

[Dmitry Titov, 2017/02/14 05:41:31]

This can be any id scoped to the name space provider specified... Can we just
call it 'id' w/o expectation that it is a guid-like-formatted string?

Also, 2 different namespaces may have overlapping ids, right?

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Good idea!  I think that's ok.  Updating it.
I'd say no for now only because some of the UI depends on the guid being unique,
but I can relax the restriction for now until it looks like we need it (and then
maybe I can concat the namespace and the id or something).

+
+  ContentId();
+  ContentId(const ContentId& other);
+  ContentId(const std::string& name_space, const std::string& guid);
+
+  bool operator==(const ContentId& content_id) const;
+
+  bool operator<(const ContentId& content_id) const;
+};
+
+// This struct holds the relevant pieces of information to represent an abstract
+// offline item to the front end.  This is meant to be backed by components that
+// need to both show content being offlined (downloading, saving, etc.) as well
+// as content that should be exposed as available offline (downloads, pages,
+// etc.).
+//
+// A new feature should expose these OfflineItems via an OfflineContentProvider.
+struct OfflineItem {

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Quick note on all of these fields:  I pulled most of these from the existing
DownloadHistoryItemWrapper.  I fully expect this list to flux a bit as the UI is
migrated over to this code.  To that end, you all have good questions and I
think removing most of these fields that are in question for now makes the most
sense.  As I need to add them back for the UI we can have targeted discussions
as necessary.  Sorry for the churn!

+ public:
+  OfflineItem();
+  OfflineItem(const OfflineItem& other);
+  explicit OfflineItem(const ContentId& id);
+
+  ~OfflineItem();
+
+  bool operator==(const OfflineItem& offline_item) const;
+
+  // The id of this OfflineItem.  Used to identify this item across all relevant
+  // systems.
+  ContentId id;
+
+  // Display Metadata.
+  // ---------------------------------------------------------------------------
+  // The title of the OfflineItem to display in the UI.
+  std::string title;
+
+  // The description of the OfflineItem to display in the UI (may or may not be
+  // displayed depending on the specific UI component).
+  std::string description;
+
+  // The URL of the icon that should be used to represent this offline item.  If
+  // |icon_url| is empty a default one will be used based on |filter|.
+  std::string icon_url;

[Dmitry Titov, 2017/02/14 05:41:31]

What about offline scenarios, is this supposed to be a data: url or some other
one?

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Will remove in the short term.  Good point.  It might make sense to expose a
RequestIconForItem(Callback, const ContentId& id) to each
OfflineContentProvider.  I don't want us to have to shoot a bunch of data to
Java and we should only pull icons as the items become (or nearly become)
visible.  Will remove now with a TODO to investigate icons.

+
+  // The type of offline item this is.  This can be used for filtering offline
+  // items as well as for determining which default icon to use.
+  OfflineItemFilter filter;

[Dmitry Titov, 2017/02/14 05:41:31]

This feels related to "file extension" field below. And also like a mime-type.
Maybe only one value (not sure which type, the mime type would be better
perhaps) is needed on the Item.

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Can we detect offline pages via the mime type?  Currently it looks like for
typical downloads we just use the mime type to generate the filter (video,
audio, image, document, other).  But pages manually sets the entry to page.

We could agree on a custom mime type for offline pages I guess?  wdyt?

+
+  // Content Metadata.
+  // ---------------------------------------------------------------------------
+  // The total size of the offline item as best known at the current time.
+  int64_t total_size_bytes;
+
+  // The extension type of the offline content.  Can be |FILE_EXTENSION_OTHER|
+  // if there is no appropriate file extension for the offline content.
+  OfflineItemFileExtension file_type;

[Dmitry Titov, 2017/02/14 05:41:31]

Is this for the same reason as mime-type would be used? Many mime types have
multiple extensions, would be good to either have mime-type if possible or
illustrate how this is going to be used so providers may supply correct values.

[qinmin, 2017/02/14 07:37:20]

why extension, not mime type?

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Yeah you guys have a good point.  See my comment on
offline_item_file_extension.h and at the top of this struct for why I added
this.  Can remove for now :).

+
+  // Whether or not this item has been removed externally (not by Chrome).
+  bool externally_removed;
+
+  // The time when the underlying offline content was created.
+  base::Time creation_time;
+
+  // The last time the underlying offline content was accessed.
+  base::Time last_accessed_time;
+
+  // Request Metadata.
+  // ---------------------------------------------------------------------------
+  // The URL of the top level frame at the time the content was offlined.
+  std::string page_url;
+
+  // The URL that represents the original request (before any redirection).
+  std::string original_url;
+
+  // The referrer URL for the request.
+  std::string referrer_url;

[Dmitry Titov, 2017/02/14 05:41:31]

Might not exist... Does UI need to know? 

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

We need to know to add files to the Android download manager.  I can remove it
for now though.  I would prefer that code went through another path and not
through the UI provider anyway :).

+
+  // Whether or not this item request started from a user gesture.
+  bool is_user_gesture;

[Dmitry Titov, 2017/02/14 05:41:31]

What is this used for? This may be not an easy bit to set (sometimes ambiguous,
as in async loading of a page), so the more explicit purpose may help providers
set it.

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Used to determine whether or not to automatically open the download when it's
done downloading.  I think this will eventually be moved to another flow as
well.  Removing.

+
+  // Whether or not this item is off the record.
+  bool is_off_the_record;
+
+  // In Progress Metadata.
+  // ---------------------------------------------------------------------------
+  // The current state of the OfflineItem.
+  OfflineItemState state;
+
+  // Whether or not the offlining of this content can be resumed if it was
+  // paused or interrupted.
+  bool is_resumable;
+
+  // The current amount of bytes received for this item.
+  int64_t received_size_bytes;

[Dmitry Titov, 2017/02/14 05:41:31]

Comment could also say what happens when item becomes fully received. Same about
next two.

[David Trainor- moved to gerrit, 2017/02/22 01:23:12]

Marked them as unused if |state| is COMPLETE.  Let me know if that's a good
approach or if you'd rather I specify specific values for these in that
situation.

+
+  // How complete (from 0 to 100) the offlining process is for this item.  -1
+  // represents that progress cannot be determined for this item and an
+  // indeterminate progress bar should be used.
+  int percent_completed;
+
+  // The estimated time remaining for the download in milliseconds.  -1
+  // represents an unknown time remaining.
+  int64_t time_remaining_ms;
+};
+
+}  // namespace offline_content
+
+#endif  // COMPONENTS_OFFLINE_CONTENT_OFFLINE_ITEM_H_