mojo leveldb: Get profile and leveldb connected to DOMStorageContext.

components/leveldb/leveldb_app.h

Index: components/leveldb/leveldb_app.h
diff --git a/components/leveldb/leveldb_app.h b/components/leveldb/leveldb_app.h
index d9877d95b3957e80303bec62efe98f226686c5b4..e830048f8dfb50f7fb022eee399b695578e4a931 100644
--- a/components/leveldb/leveldb_app.h
+++ b/components/leveldb/leveldb_app.h
@@ -13,6 +13,8 @@
 
 namespace leveldb {
 
+scoped_ptr<mojo::ShellClient> CreateLevelDBApp();
+
 class LevelDBApp : public mojo::ShellClient,

[Ben Goodger (Google), 2016/03/04 20:50:49]

Can you explain why the LevelDB functionality is a discrete application with its
own identity (as far as the shell is concerned), as differentiated from your
comment in the profile service file that talks about different interfaces (e.g.
preferences) vended by the profile application?

reasons to have a separate application:
- this code has a different capability requirements than other code exposed by
profile service
- this code wants to be run in a different sandbox
- this code runs as a specific user where the profile service runs as all users
(I don't think this is the case?)
- you expect (at some point in the future) this code to be packaged separately
from the profile service.
- maybe others?

I can see two views of the profile service. One is that it is a very simple
broker of access to directories and offers no other interfaces. Everything else
is implemented as separate applications layered on top, ultimately with the mind
that they're even packaged separately, run in different processes.
Another is that it's an aggregator of all user-related state, brokering
directory access & providing access to other things like leveldb, profile, etc.
Which do you have in mind?

[Ben Goodger (Google), 2016/03/04 22:13:16]

For the curious, Elliot & I discussed this offline.

In this CL the application concept is being used to get thread isolation for
leveldb vs. filesystem impls, which interact poorly when they live on the same
thread.

My suggestion is instead of using an application for LevelDB, make the profile
application vend a LevelDB interface via its service provider, and when
requested bind that interface request on a different thread:

profile_app.cc:

bool ProfileApp::AcceptConnection(Connection* conn) {
  ..
  conn->AddInterface<LevelDB>(this);
}

..

void ProfileApp::Create(Connection* conn, LevelDBRequest req) {
  new LevelDBThread(std::move(req));
}

class LevelDBThread : public base::SimpleThread {
..
};

                    public mojo::InterfaceFactory<LevelDBService> {
  public:
@@ -20,6 +22,10 @@ class LevelDBApp : public mojo::ShellClient,
   ~LevelDBApp() override;
 
  private:
+  // Tracks connection errors and shuts the application down when all
+  // outstanding connections to |bindings_| have gone away.
+  void OnConnectionError();
+
   // |ShellClient| override:
   void Initialize(mojo::Connector* connector,
                   const std::string& url,
@@ -27,9 +33,6 @@ class LevelDBApp : public mojo::ShellClient,
                   uint32_t user_id) override;
   bool AcceptConnection(mojo::Connection* connection) override;
 
-  // TODO(erg): What do we have to do on shell error?
-  // bool OnShellConnectionError() override;
-
   // |InterfaceFactory<LevelDBService>| implementation:
   void Create(mojo::Connection* connection,
               mojo::InterfaceRequest<LevelDBService> request) override;
@@ -38,6 +41,8 @@ class LevelDBApp : public mojo::ShellClient,
   scoped_ptr<LevelDBService> service_;
   mojo::BindingSet<LevelDBService> bindings_;
 
+  int outstanding_bindings_;
+
   DISALLOW_COPY_AND_ASSIGN(LevelDBApp);
 };