FrameMojoShell provides services to mojo apps.

content/browser/frame_host/frame_mojo_shell.h

 // Copyright 2015 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_BROWSER_FRAME_HOST_FRAME_MOJO_SHELL_H_
 #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"
 
 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.
 class FrameMojoShell : public mojo::Shell {
  public:
   explicit FrameMojoShell(RenderFrameHost* frame_host);
   ~FrameMojoShell() override;
 
   void BindRequest(mojo::InterfaceRequest<mojo::Shell> shell_request);
 
  private:
   // mojo::Shell:
   void ConnectToApplication(
       mojo::URLRequestPtr application_url,
       mojo::InterfaceRequest<mojo::ServiceProvider> services,
       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);
 };
 
 }  // namespace content
 
 #endif  // CONTENT_BROWSER_FRAME_HOST_FRAME_MOJO_SHELL_H_