mojo leveldb: Get profile and leveldb connected to DOMStorageContext.

components/profile_service/profile_app.h

 // 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 COMPONENTS_PROFILE_SERVICE_PROFILE_APP_H_
 #define COMPONENTS_PROFILE_SERVICE_PROFILE_APP_H_
 
+#include "base/memory/ref_counted.h"
 #include "components/filesystem/lock_table.h"
 #include "components/leveldb/public/interfaces/leveldb.mojom.h"
 #include "components/profile_service/public/interfaces/profile.mojom.h"
 #include "mojo/public/cpp/bindings/binding_set.h"
 #include "mojo/services/tracing/public/cpp/tracing_impl.h"
 #include "mojo/shell/public/cpp/interface_factory.h"
+#include "mojo/shell/public/cpp/message_loop_ref.h"
 #include "mojo/shell/public/cpp/shell_client.h"
 
 namespace filesystem {
 class LockTable;
 }
 
 namespace profile {
+class LevelDBThread;
 
 scoped_ptr<mojo::ShellClient> CreateProfileApp();
 
 // Application which hands off per-profile services.
 //
-// This Application serves ProfileService, and serves LevelDBService since most
-// of the users of leveldb will want to write directly to the Directory
-// provided by the ProfileService; we want file handling to be done in the same
-// process to minimize IPC.
-//
-// In the future, this application will probably also offer any service that
-// most Profile using applications will need, such as preferences.
+// This Application serves ProfileService. In the future, this application will
+// probably also offer any service that most Profile using applications will
+// need, such as preferences, but these will need to be served off of separate

[Ben Goodger (Google), 2016/03/11 23:21:38]

Why make the generic statement that all interfaces will have to be served off of
different threads? I don't think that's true. (Unless you can tell me why it
is.)

[Elliot Glaysher, 2016/03/14 20:33:20]

Removed comment about threading.

+// threads; this class will have to be made into a application which is an
+// InterfaceProvider which internally spawns threads for different
+// sub-applications.
 class ProfileApp : public mojo::ShellClient,
                    public mojo::InterfaceFactory<ProfileService>,
                    public mojo::InterfaceFactory<leveldb::LevelDBService> {
  public:
   ProfileApp();
   ~ProfileApp() override;
 
   // Currently, ProfileApp is run from within the chrome process. This means it
   // that the ApplicationLoader is registered during MojoShellContext startup,
   // even though the application itself is not started. As soon as a
@@ skipping 23 matching lines @@
 
   // |InterfaceFactory<LevelDBService>| implementation:
   void Create(mojo::Connection* connection,
               leveldb::LevelDBServiceRequest request) override;
 
   mojo::TracingImpl tracing_;
 
   scoped_ptr<ProfileService> profile_service_;
   mojo::BindingSet<ProfileService> profile_bindings_;
 
-  scoped_ptr<leveldb::LevelDBService> leveldb_service_;
-  mojo::BindingSet<leveldb::LevelDBService> leveldb_bindings_;
+  scoped_ptr<filesystem::LockTable> lock_table_;
+  base::FilePath profile_data_dir_;
 
-  scoped_ptr<filesystem::LockTable> lock_table_;
+  scoped_refptr<LevelDBThread> leveldb_thread_;
 
-  base::FilePath profile_data_dir_;
+  mojo::MessageLoopRefFactory ref_factory_;
 
   DISALLOW_COPY_AND_ASSIGN(ProfileApp);
 };
 
 }  // namespace profile
 
 #endif  // COMPONENTS_PROFILE_SERVICE_PROFILE_APP_H_