Embed a mojo ApplicationManager in content/browser

content/public/browser/content_browser_client.h

 // Copyright (c) 2012 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_CONTENT_BROWSER_CLIENT_H_
 #define CONTENT_PUBLIC_BROWSER_CONTENT_BROWSER_CLIENT_H_
 
 #include <map>
 #include <string>
 #include <utility>
@@ skipping 63 matching lines @@
 
 namespace storage {
 class ExternalMountPoints;
 class FileSystemBackend;
 }
 
 namespace content {
 
 enum class PermissionType;
 class AccessTokenStore;
+class ApplicationRegistry;
 class BrowserChildProcessHost;
 class BrowserContext;
 class BrowserMainParts;
 class BrowserPluginGuestDelegate;
 class BrowserPpapiHost;
 class BrowserURLHandler;
 class ClientCertificateDelegate;
 class DevToolsManagerDelegate;
 class ExternalVideoSurfaceContainer;
 class LocationProvider;
@@ skipping 477 matching lines @@
   // Allows to override browser Mojo services exposed through the
   // RenderProcessHost.
   virtual void OverrideRenderProcessMojoServices(ServiceRegistry* registry) {}
 
   // Allows to override browser Mojo services exposed through the
   // RenderFrameHost.
   virtual void OverrideRenderFrameMojoServices(
       ServiceRegistry* registry,
       RenderFrameHost* render_frame_host) {}
 
+  // Registers in-process Mojo application loaders with the browser's global
+  // Mojo shell.
+  virtual void RegisterMojoApplications(ApplicationRegistry* registry) {}

[jam, 2015/05/29 01:48:54]

why call the embedder and give it another interface so that it can call it back?
i.e. why not just give it here a vector of GURL/StaticAppFactory that it can
push_back?

[Ken Rockot(use gerrit already), 2015/05/29 03:20:40]

I think there are a few decent reasons:

 - I experimented with passing in a map and it adds lots of code,
   mostly because:
 - There's no need to allocate extra containers in some cases;
   MojoShellContext for example doesn't hold a map of its own, it
   just forwards URL/Loader pairs to ApplicationManager.
 - We eventually need to register more than just static factories
 - Things which hold URL/app mappings may want to hand out a
   registration interface to more than just Content*Client.

[jam, 2015/05/29 15:11:50]

I'm not sure I understand what you mean here.

are you saying that it's inefficient to copy the stl container class?
why?
examples?

in general, for content api (per link in previous round of reviews) we try to be
as minimal as possible. what can be done with one method shouldn't be done with
a method and interface

+
   // Registers additional navigator.connect service factories available in a
   // particular NavigatorConnectContext.
   virtual void GetAdditionalNavigatorConnectServices(
       const scoped_refptr<NavigatorConnectContext>& context) {}
 
   // Allows to override the visibility state of a RenderFrameHost.
   // |visibility_state| should not be null. It will only be set if needed.
   virtual void OverridePageVisibilityState(
       RenderFrameHost* render_frame_host,
       blink::WebPageVisibilityState* visibility_state) {}
@@ skipping 37 matching lines @@
   // Allows an embedder to provide its own ExternalVideoSurfaceContainer
   // implementation.  Return nullptr to disable external surface video.
   virtual ExternalVideoSurfaceContainer*
   OverrideCreateExternalVideoSurfaceContainer(WebContents* web_contents);
 #endif
 };
 
 }  // namespace content
 
 #endif  // CONTENT_PUBLIC_BROWSER_CONTENT_BROWSER_CLIENT_H_