Proposal: Allow the use of Mojo from Blink

[Sam McNally]

I'd like to use Mojo to communicate from API implementations in Blink with the browser implementation. This would replace Web*Client interfaces and their implementations provided by a Platform, WebFrameClient etc.

Using Mojo from Blink requires:

• adding a dependency from blink to mojo (adding third_party/mojo/src/mojo/public, mojo/common and mojo/application/public/cpp to DEPS);
  
• moving the mojo interfaces from content/(public/)common to components/<name>/public/interfaces;
  
• adding a dependency from blink to components/<name>/public/interfaces;
  
• adding a mojo::ServiceProvider to ExecutionContext (or some other easily accessed object); and
  
• a way to interface with mojo::Callback.
  

How to interface with mojo::Callback?

base::Bind:

• works with mojo::Callback
  
• requires adding a dependency on part of base [0]
  
• semantics are quite different to WTF::bind [1]
  

lambdas:

• works with mojo::Callback
• equivalent to base::Bind in terms of ownership/lifetime management when interacting with mojo services
  
• banned by [2] in favour of base::Bind for this use case
  

WTF::bind:

• requires an adapter to work with mojo::Callback
  
• doesn't support calling Pass() on move-only mojo structs
  
• semantics are actually similar to how mojo uses callbacks
• callbacks to mojo services are:
• only called once
• only called on the thread on which the service lives
• mojo::Callback is not thread-safe

See [3] for a prototype implementation for geolocation.

[0] https://groups.google.com/a/chromium.org/d/topic/blink-dev/rjy64WpOfSc/discussion

[1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/rjy64WpOfSc/XFYKmJUgBQAJ

[2] https://chromium-cpp.appspot.com/

[3] https://codereview.chromium.org/1367853002

[Elliott Sprehn]

I'd rather not allow ServiceProvider access from anywhere inside blink, having IPCs come from "anywhere" makes reasoning about the behavior of the system extremely difficult, especially given that Mojo has sync ipc wait primitives.

I think allowing this in platform/ is probably reasonable.

I'm currently working on an architecture plan for blink that should make where we're going with layering, base, platform, wtf and IPCs more clear as well. I'll have it to share next week. :)

[Elliott Sprehn]

I'm also curious how Mojo integrates with the scheduler, in your example the Gelocation callbacks should happen based on when the scheduler thinks it's a good time to do so, which means I'd hope the IPC response task would be captured by the scheduler, and then executed at the correct time.

In blink I'd like for us to move away from Timer<>, postTask, and other things and only ever execute async tasks through the scheduler. Mojo IPC responses should be included. Is this handled already through some MessageLoop magic?

[Sam McNally]

On Fri, 2 Oct 2015 at 17:37 Elliott Sprehn <esp...@chromium.org> wrote:

I'm also curious how Mojo integrates with the scheduler, in your example the Gelocation callbacks should happen based on when the scheduler thinks it's a good time to do so, which means I'd hope the IPC response task would be captured by the scheduler, and then executed at the correct time.

In blink I'd like for us to move away from Timer<>, postTask, and other things and only ever execute async tasks through the scheduler. Mojo IPC responses should be included. Is this handled already through some MessageLoop magic?

In the renderer Mojo implicitly uses the scheduler's default task runner (it indirectly uses base::ThreadTaskRunnerHandle::Get(), which returns the scheduler's default task runner). I believe chrome IPC works similarly.

On Fri, Oct 2, 2015 at 2:17 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd rather not allow ServiceProvider access from anywhere inside blink, having IPCs come from "anywhere" makes reasoning about the behavior of the system extremely difficult, especially given that Mojo has sync ipc wait primitives.

I think allowing this in platform/ is probably reasonable.

I'm currently working on an architecture plan for blink that should make where we're going with layering, base, platform, wtf and IPCs more clear as well. I'll have it to share next week. :)

Sounds great. I'm looking forward to it. 

[Darin Fisher]

On Tue, Oct 6, 2015 at 12:32 AM, Sam McNally <sa...@chromium.org> wrote:

On Fri, 2 Oct 2015 at 17:37 Elliott Sprehn <esp...@chromium.org> wrote:

I'm also curious how Mojo integrates with the scheduler, in your example the Gelocation callbacks should happen based on when the scheduler thinks it's a good time to do so, which means I'd hope the IPC response task would be captured by the scheduler, and then executed at the correct time.

In blink I'd like for us to move away from Timer<>, postTask, and other things and only ever execute async tasks through the scheduler. Mojo IPC responses should be included. Is this handled already through some MessageLoop magic?

In the renderer Mojo implicitly uses the scheduler's default task runner (it indirectly uses base::ThreadTaskRunnerHandle::Get(), which returns the scheduler's default task runner). I believe chrome IPC works similarly.

On Fri, Oct 2, 2015 at 2:17 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd rather not allow ServiceProvider access from anywhere inside blink, having IPCs come from "anywhere" makes reasoning about the behavior of the system extremely difficult, especially given that Mojo has sync ipc wait primitives.

I think allowing this in platform/ is probably reasonable.

I'm currently working on an architecture plan for blink that should make where we're going with layering, base, platform, wtf and IPCs more clear as well. I'll have it to share next week. :)

Sounds great. I'm looking forward to it. 

By the way, it seems like it would be worth considering whether Blink should use Mojo IPC with //base or sans-//base. Either is possible.

-Darin

[Ken Rockot]

On Tue, Oct 6, 2015 at 9:18 AM, Darin Fisher <da...@chromium.org> wrote:

On Tue, Oct 6, 2015 at 12:32 AM, Sam McNally <sa...@chromium.org> wrote:

On Fri, 2 Oct 2015 at 17:37 Elliott Sprehn <esp...@chromium.org> wrote:

I'm also curious how Mojo integrates with the scheduler, in your example the Gelocation callbacks should happen based on when the scheduler thinks it's a good time to do so, which means I'd hope the IPC response task would be captured by the scheduler, and then executed at the correct time.

In blink I'd like for us to move away from Timer<>, postTask, and other things and only ever execute async tasks through the scheduler. Mojo IPC responses should be included. Is this handled already through some MessageLoop magic?

In the renderer Mojo implicitly uses the scheduler's default task runner (it indirectly uses base::ThreadTaskRunnerHandle::Get(), which returns the scheduler's default task runner). I believe chrome IPC works similarly.

On Fri, Oct 2, 2015 at 2:17 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd rather not allow ServiceProvider access from anywhere inside blink, having IPCs come from "anywhere" makes reasoning about the behavior of the system extremely difficult, especially given that Mojo has sync ipc wait primitives.

I think allowing this in platform/ is probably reasonable.

I'm currently working on an architecture plan for blink that should make where we're going with layering, base, platform, wtf and IPCs more clear as well. I'll have it to share next week. :)

Any updates on this plan?

 

Sounds great. I'm looking forward to it. 

By the way, it seems like it would be worth considering whether Blink should use Mojo IPC with //base or sans-//base. Either is possible.

Sam, is there anything stopping us from making an adapter to get a mojo::Callback from a WTF::Function?

[Sam McNally]

On Wed, 21 Oct 2015 at 05:02 Ken Rockot <roc...@chromium.org> wrote:

On Tue, Oct 6, 2015 at 9:18 AM, Darin Fisher <da...@chromium.org> wrote:

On Tue, Oct 6, 2015 at 12:32 AM, Sam McNally <sa...@chromium.org> wrote:

On Fri, 2 Oct 2015 at 17:37 Elliott Sprehn <esp...@chromium.org> wrote:

I'm also curious how Mojo integrates with the scheduler, in your example the Gelocation callbacks should happen based on when the scheduler thinks it's a good time to do so, which means I'd hope the IPC response task would be captured by the scheduler, and then executed at the correct time.

In blink I'd like for us to move away from Timer<>, postTask, and other things and only ever execute async tasks through the scheduler. Mojo IPC responses should be included. Is this handled already through some MessageLoop magic?

In the renderer Mojo implicitly uses the scheduler's default task runner (it indirectly uses base::ThreadTaskRunnerHandle::Get(), which returns the scheduler's default task runner). I believe chrome IPC works similarly.

On Fri, Oct 2, 2015 at 2:17 AM, Elliott Sprehn <esp...@chromium.org> wrote:

I'd rather not allow ServiceProvider access from anywhere inside blink, having IPCs come from "anywhere" makes reasoning about the behavior of the system extremely difficult, especially given that Mojo has sync ipc wait primitives.

I think allowing this in platform/ is probably reasonable.

I'm currently working on an architecture plan for blink that should make where we're going with layering, base, platform, wtf and IPCs more clear as well. I'll have it to share next week. :)

Any updates on this plan?

 

Sounds great. I'm looking forward to it. 

By the way, it seems like it would be worth considering whether Blink should use Mojo IPC with //base or sans-//base. Either is possible.

Sam, is there anything stopping us from making an adapter to get a mojo::Callback from a WTF::Function?

An adapter is fairly straightforward, but we'd need to use base::internal::CallbackForward and base::internal::CallbackParamTraits (or something similar) in both the adapter and WTF::Function to support forwarding of move-only mojo types.