mojo leveldb: Get profile and leveldb connected to DOMStorageContext.

components/leveldb/leveldb_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_LEVELDB_LEVELDB_APP_H_
 #define COMPONENTS_LEVELDB_LEVELDB_APP_H_
 
 #include "components/leveldb/public/interfaces/leveldb.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/shell_client.h"
 
 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:
   LevelDBApp();
   ~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,
                   uint32_t id,
                   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;
 
   mojo::TracingImpl tracing_;
   scoped_ptr<LevelDBService> service_;
   mojo::BindingSet<LevelDBService> bindings_;
 
+  int outstanding_bindings_;
+
   DISALLOW_COPY_AND_ASSIGN(LevelDBApp);
 };
 
 }  // namespace leveldb
 
 #endif  // COMPONENTS_LEVELDB_LEVELDB_APP_H_