PaymentApp: Introduce PaymentAppDatabase class.

content/public/browser/payment_app_context.h

Index: content/public/browser/payment_app_context.h
diff --git a/content/public/browser/payment_app_context.h b/content/public/browser/payment_app_context.h
new file mode 100644
index 0000000000000000000000000000000000000000..4ec84a37e0d5a1e5f148a34eaea6acfac891ca0b
--- /dev/null
+++ b/content/public/browser/payment_app_context.h
@@ -0,0 +1,29 @@
+// Copyright 2016 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 CONTENT_PUBLIC_BROWSER_PAYMENT_APP_CONTEXT_H_
+#define CONTENT_PUBLIC_BROWSER_PAYMENT_APP_CONTEXT_H_
+
+#include <utility>
+#include <vector>
+
+#include "base/callback_forward.h"
+
+namespace content {
+
+class PaymentAppContext {
+ public:
+  // The ManifestWithID is a pair of the service worker registration id and
+  // the payment app manifest data associated with it.
+  using ManifestWithID =
+      std::pair<int64_t, payments::mojom::PaymentAppManifestPtr>;

[please use gerrit instead, 2016/12/09 23:56:30]

tommyt@'s implementation of PaymentAppManifest uses scopeUrl to identify payment
apps. You two should reconcile this difference ;-)

https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chr...

[zino, 2016/12/10 00:19:58]

Sure,

As I remember, we already discussed about it. :)

To clarify, I left this comment.

I think it's favorable to use registration_id.
Because most of service worker APIs in content layer takes registration id
instead of scope_url. We can use scope_url but we will have to find
a SW registration with scope_url once more to find the registration id.

If some API is initiated in blink side, scope_url can be necessary because
the registration id is generated in content/child.
(e.g. paymentManager.setManifest())

On the other hands, some API is initiated in chromium side,
registration_id is enough. (e.g. invokePaymentApp())

[tommyt, 2016/12/10 10:04:47]

I'm fine with switching to int64_t, and I even have a WIP change that does that.
There is no known requirement for knowing this scopeUrl in the UI, so there is
no particular reason to keep it there.

+  using Manifests = std::vector<ManifestWithID>;
+  using GetAllManifestsCallback = base::Callback<void(const Manifests&)>;
+
+  virtual void GetAllManifests(const GetAllManifestsCallback& callback) = 0;
+};
+
+}  // namespace content
+
+#endif  // CONTENT_PUBLIC_BROWSER_PAYMENT_APP_CONTEXT_H_