mojo leveldb: Get profile and leveldb connected to DOMStorageContext.

components/profile_service/profile_service_impl.cc

Index: components/profile_service/profile_service_impl.cc
diff --git a/components/profile_service/profile_service_impl.cc b/components/profile_service/profile_service_impl.cc
index b6239dd706459860cd7bc7d52bf90d00d965cbfe..b27512c925f17ad425b880c8c7f1b8778ce7f261 100644
--- a/components/profile_service/profile_service_impl.cc
+++ b/components/profile_service/profile_service_impl.cc
@@ -4,6 +4,7 @@
 
 #include "components/profile_service/profile_service_impl.h"
 
+#include "base/bind.h"
 #include "base/files/file_path.h"
 #include "base/files/file_util.h"
 #include "base/files/scoped_temp_dir.h"
@@ -16,24 +17,33 @@ namespace profile {
 ProfileServiceImpl::ProfileServiceImpl(
     mojo::Connection* connection,
     mojo::InterfaceRequest<ProfileService> request,
+    base::Closure on_service_destroyed,
     base::FilePath base_profile_dir,
     filesystem::LockTable* lock_table)
     : binding_(this, std::move(request)),
+      on_service_destroyed_(on_service_destroyed),
       lock_table_(lock_table),
       path_(base_profile_dir) {
   if (!base::PathExists(path_))
     base::CreateDirectory(path_);
+  binding_.set_connection_error_handler(base::Bind(
+      &ProfileServiceImpl::OnConnectionError, base::Unretained(this)));
 }
 
-ProfileServiceImpl::~ProfileServiceImpl() {
-}
+ProfileServiceImpl::~ProfileServiceImpl() {}
 
 void ProfileServiceImpl::GetDirectory(
-    mojo::InterfaceRequest<filesystem::Directory> request) {
+    mojo::InterfaceRequest<filesystem::Directory> request,
+    const GetDirectoryCallback& callback) {

[michaeln, 2016/03/05 01:38:54]

Would it make sense to have a variant that accepts a FilePath? If a full
filepath is provided, it must a child of this->path_. If a relative filepath is
provided, it means path_.AppendRelativePath.

I suppose callers can call profile_directory_.OpenDirectory() but notice that in
the local storage case, current code doesn't actually know the relative path
from {profiledir} to leveldb file, however we do know the fullpath.

I'm noticing that To open a subdirectory thats nested down a couple levels
requires mulitple async calls to dir.OpenDirectory(), one for each nesting level
down.

[Elliot Glaysher, 2016/03/10 21:00:35]

Yes. Previously that's how this worked, but in a previous patch, I pulled it out
due to reviewer comments.

(Given your other comments about which directory under the profile dir we need
to write to, I went and added it back.)

   new filesystem::DirectoryImpl(std::move(request),
                                 path_,
                                 scoped_ptr<base::ScopedTempDir>(),
                                 lock_table_);
+  callback.Run(filesystem::FileError::OK);
+}
+
+void ProfileServiceImpl::OnConnectionError() {
+  on_service_destroyed_.Run();
 }
 
 }  // namespace profile