A prototype for using Mojo services from a Pepper plugin.

[Justin TerAvest]

I'm pleased to say that I've got a (hacky) prototype working for an
(out-of-process, non-NaCl) Pepper plugin using a remote Mojo service
in the browser.

The change is available at: https://codereview.chromium.org/598183002

A "bootstrap" MojoPlatformHandle is provided to the plugin as the result of a
PPB_Mojo::GetHandle call, and the plugin can then use Mojo embedder libraries
to create a channel and use Mojo libraries to talk to services. I like that
this approach keeps the proxy simple and allows the plugin to use the "normal"
Mojo interfaces. I'd love any feedback on this approach.

For the prototype, the browser side creates an implementation of the
EchoService for testing. I'm assuming we'll have some sort of service
name whitelist in pepper_mojo_host.cc to restrict the services a plugin can
connect to, but I'm not sure yet how we should add services to make them
available.

Some open issues remain:
* This needs to support NaCl (large amount of work here).
* I'm not convinced that Environment/RunLoop are being used properly in the
plugin code here. I don't see these classes being used in the
MojoApplication code in the renderer, but the code didn't work without
them.
* The browser code needs to support more than one GetHandle() call.

[Viet-Trung Luu]

This seems wrong:

mojo/embedder is not a stable interface, and is only meant to be used by the host (e.g., chromium).

A plausible PPB_Mojo would provide access to the various functions in mojo/public/c/system, and some sort of "GetHandle()" which gets a MojoHandle (for a service manager).

To unsubscribe from this group and stop receiving emails from it, send an email to mojo-dev+u...@chromium.org.

[Justin TerAvest]

Thanks for the quick response!

On Wed, Sep 24, 2014 at 3:07 PM, Viet-Trung Luu <v...@google.com> wrote:
> This seems wrong:
>
> mojo/embedder is not a stable interface, and is only meant to be used by the
> host (e.g., chromium).

I see. I'll rework this to not expose any use of mojo::embedder to
Pepper plugins.

>
> A plausible PPB_Mojo would provide access to the various functions in
> mojo/public/c/system, and some sort of "GetHandle()" which gets a MojoHandle
> (for a service manager).

Assuming that plugins only want to bind a service to a MojoHandle and
call through stubs,
why would PPB_Mojo have to provide access to the functions in
mojo/public/c/system?

Hiding some of the embedder logic (and perhaps use of
mojo::ServiceProvider), I could imagine a PPB_Mojo interface that just
has:
MojoHandle GetHandleForService(const char* service_name)

where the plugin code would (roughly) do:
PPB_Mojo* ppb_mojo;
MojoHandle h = ppb_mojo->GetHandleForService("ExampleService");
example_service_.Bind(h);
example_service_->SomeCall(...);

Why would PPB_Mojo expose functions like MojoCreateDataPipe,
MojoBeginReadData, or MojoWriteMessage to a plugin?

[Viet-Trung Luu]

On Wed, Sep 24, 2014 at 3:03 PM, Justin TerAvest <tera...@chromium.org> wrote:

Thanks for the quick response!

On Wed, Sep 24, 2014 at 3:07 PM, Viet-Trung Luu <v...@google.com> wrote:
> This seems wrong:
>
> mojo/embedder is not a stable interface, and is only meant to be used by the
> host (e.g., chromium).

I see. I'll rework this to not expose any use of mojo::embedder to
Pepper plugins.

>
> A plausible PPB_Mojo would provide access to the various functions in
> mojo/public/c/system, and some sort of "GetHandle()" which gets a MojoHandle
> (for a service manager).

Assuming that plugins only want to bind a service to a MojoHandle and
call through stubs,
why would PPB_Mojo have to provide access to the functions in
mojo/public/c/system?

What good is a MojoHandle without access to those functions?

 

Hiding some of the embedder logic (and perhaps use of
mojo::ServiceProvider), I could imagine a PPB_Mojo interface that just
has:
MojoHandle GetHandleForService(const char* service_name)

where the plugin code would (roughly) do:
PPB_Mojo* ppb_mojo;
MojoHandle h = ppb_mojo->GetHandleForService("ExampleService");
example_service_.Bind(h);
example_service_->SomeCall(...);

You can't do any of that without access to those functions.

[Justin TerAvest]

There's some detail I'm still missing.

This prototype change works fine without exposing extra functions in PPB_Mojo.
Is the problem that the prototype plugin is using an implementation of
mojo/public/c/system that won't work inside the NaCl sandbox?

[Viet-Trung Luu]

Try linking a proper standalone plugin. Make sure you're using a static build, not a shared library build.

[Nick Bray]

I think that we may want to ultimately skip the trusted plugin case.  It's a good test bed for getting the plumbing in place, but is there an expected used case?  If we do want to support the trusted case, it may be possible to have the PPAPI plugin export an (optional) function for setting thunks, just like a Mojo app does:

https://code.google.com/p/chromium/codesearch#chromium/src/mojo/shell/in_process_dynamic_service_runner.cc&sq=package:chromium&l=94

For NaCl PPAPI plugins, mojo/public/c/system can be exposed through the IRT.  PPAPI only needs to provide the initial handle.

Justin and I will be VCing tomorrow at 10, anyone who wants to join the chat is welcome.

[Viet-Trung Luu]

On Wed, Sep 24, 2014 at 4:31 PM, Nick Bray <ncb...@google.com> wrote:

I think that we may want to ultimately skip the trusted plugin case.  It's a good test bed for getting the plumbing in place, but is there an expected used case?  If we do want to support the trusted case, it may be possible to have the PPAPI plugin export an (optional) function for setting thunks, just like a Mojo app does:

https://code.google.com/p/chromium/codesearch#chromium/src/mojo/shell/in_process_dynamic_service_runner.cc&sq=package:chromium&l=94

For NaCl PPAPI plugins, mojo/public/c/system can be exposed through the IRT.  PPAPI only needs to provide the initial handle.

You can provide mojo/public/c/system in any number of ways, though if you want to be consistent with Pepper, it seems sensible to use its mechanism for providing function tables.

Having the plugin export a thunk-setting function is possible too. This is called a "PPP" interface in Pepper land, though it'd be a bit unusual for the thunk-setting function to be called unbidden. Adding yet another mechanism would seem odd.

 

Exposing mojo/public/c/system via the IRT for NaCl PPAPI plugins would be consistent with the story for NaCl Mojo apps. It's still a bit odd (because a PPAPI plugin will never be just a Mojo app, since it doesn't own its main thread), but then the IRT is a bit odd.