FrameMojoShell provides services to mojo apps.

content/browser/frame_host/frame_mojo_shell.h

Index: content/browser/frame_host/frame_mojo_shell.h
diff --git a/content/browser/frame_host/frame_mojo_shell.h b/content/browser/frame_host/frame_mojo_shell.h
index 3c209d2e752ab1f427be7a7508c11e94348a0817..c129178ff13b4fa4058af8c8f6b26796d7355f17 100644
--- a/content/browser/frame_host/frame_mojo_shell.h
+++ b/content/browser/frame_host/frame_mojo_shell.h
@@ -6,6 +6,7 @@
 #define CONTENT_BROWSER_FRAME_HOST_FRAME_MOJO_SHELL_H_
 
 #include "base/macros.h"
+#include "base/memory/scoped_ptr.h"
 #include "mojo/application/public/interfaces/shell.mojom.h"
 #include "mojo/common/weak_binding_set.h"
 #include "third_party/mojo/src/mojo/public/cpp/bindings/interface_request.h"
@@ -13,6 +14,7 @@
 namespace content {
 
 class RenderFrameHost;
+class ServiceRegistryImpl;
 
 // This provides the |mojo::Shell| service interface to each frame's
 // ServiceRegistry, giving frames the ability to connect to Mojo applications.
@@ -31,9 +33,14 @@ class FrameMojoShell : public mojo::Shell {
       mojo::ServiceProviderPtr exposed_services) override;
   void QuitApplication() override;
 
+  ServiceRegistryImpl* GetServiceRegistry();
+
   RenderFrameHost* frame_host_;
   mojo::WeakBindingSet<mojo::Shell> bindings_;
 
+  // ServiceRegistry providing browser services to connected applications.
+  scoped_ptr<ServiceRegistryImpl> service_registry_;

[xhwang, 2015/06/29 20:25:51]

I am debating between doing this and using the service registry in RFHI
directly. If latter, the mojo app running in the utility process will be able to
use all services RFHI provides (the same set of services provided to the render
frame in the render process). It seems a good idea for code reuse, but I am not
sure whether we are over-exposing services. For example, the service runnin in
the utility process can in turn ask for a Shell service...

[Ken Rockot(use gerrit already), 2015/07/06 18:58:00]

What you're doing here seems right to me. We should be explicit about what
services render frames expose to other apps.

Eventually a renderer will be just another OOP Mojo app rendering web contents.
We can think of this as the set of services that would be exposed by that app.

This is a good interim solution which mocks mojo shell integration but avoids
the massive amount of effort it would take to make the renderer a "real" Mojo
app.

[xhwang, 2015/07/07 19:21:04]

Acknowledged.

+

[Ken Rockot(use gerrit already), 2015/07/06 18:58:00]

Actually I think ServiceRegistry is overkill here since there's no use for the
remote service bits which comprise half of its interface.

Can you get away with making this a ServiceProviderImpl instead?
(//mojo/application/public/cpp/service_provider_impl.h). And of course
GetServiceRegistry would change to GetServiceProvider, and
OverrideFrameMojoShellServices have to take a ServiceProviderImpl* rather than a
ServiceRegistry*.

This should be OK (I think...) because if a renderer-side service needs to
access remote services it should be using C2A rather than some one-off
ServiceRegistry instance.

[xhwang, 2015/07/07 19:21:04]

As discussed offline, the current ServiceProviderImpl is pretty hard to use as
is. I could add a content::ServiceProviderImpl but that needs to be in
content/public/common, which isn't trivial. So  we'll keep using the SRI for
now.

Also, I can use WeakBindingSet here so we don't need ProxyServiceProvider
anymore.

   DISALLOW_COPY_AND_ASSIGN(FrameMojoShell);
 };