Questions about Blink-mojo bindings

50 views
Skip to first unread message

Kentaro Hara

unread,
Aug 23, 2016, 7:30:50 AM8/23/16
to chromium-mojo
Hi

Let me ask a couple of quick questions about Blink-Mojo bindings:

1) Blink sometimes uses a per-frame interface provider but sometimes use a global interface provider. Specifically, we mix the following two patterns. Do you have any preference on which pattern Blink should use?

  frame.interfaceProvider()->getInterface(&m_service);
  Platform::current()->interfaceProvider()->getInterface(&m_service);

2) Blink sometimes sets a connection error handler but not always. Should Blink set a connection error handler always? What happens if Blink forgets to set a connection error handler?

  m_service.set_connection_error_handler(...);

Thanks!

--
Kentaro Hara, Tokyo, Japan

Darin Fisher

unread,
Aug 23, 2016, 10:23:14 AM8/23/16
to Kentaro Hara, chromium-mojo
On Tue, Aug 23, 2016 at 4:30 AM, Kentaro Hara <har...@chromium.org> wrote:
Hi

Let me ask a couple of quick questions about Blink-Mojo bindings:

1) Blink sometimes uses a per-frame interface provider but sometimes use a global interface provider. Specifically, we mix the following two patterns. Do you have any preference on which pattern Blink should use?

  frame.interfaceProvider()->getInterface(&m_service);
  Platform::current()->interfaceProvider()->getInterface(&m_service);


Some services need to know what browser tab the client is associated with. For example, the WebSocket backend needs to know how to deal with certificate errors, and the user may have previously accepted a bad certificate but only for a particular tab.

With Chrome IPC, we plumb this context using identifiers called "routing IDs" or "render frame IDs." Instead, of plumbing those identifiers into Blink, we take advantage of a Mojo pipe being effectively an identifier, and then just select the appropriate Frame's InterfaceProvider.

The above makes it easy for Mojom interfaces to mimic the interfaces exposed by WebFrameClient and Platform, and indeed the same "sometimes the embedder needs to know context about which Frame something is happening in" reasoning explains why WebFrameClient exists.


 
2) Blink sometimes sets a connection error handler but not always. Should Blink set a connection error handler always? What happens if Blink forgets to set a connection error handler?

  m_service.set_connection_error_handler(...);

There are two Mojo bindings classes: mojo::Binding and mojo::StrongBinding. If you use the later, then it implicitly sets up a connection error handler and deletes the bound interface implementation when a connection error occurs. Sometimes, you will want more control over what happens when a connection error occurs, so you can use mojo::Binding instead and monitor the connection error yourself.

If you use mojo::Binding and do not observe connection error, then upon connection error, you will stop receiving incoming method calls and any outgoing method calls will just be eaten silently.

-Darin

 

Thanks!

--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CABg10jz4sAg-CNpp2U0Vi1oSQ5TkrwKROwAv%3Dq9MKF7jJqz0Ww%40mail.gmail.com.

Kentaro Hara

unread,
Aug 23, 2016, 11:01:53 AM8/23/16
to Darin Fisher, chromium-mojo
Thanks Darin!

On Tue, Aug 23, 2016 at 11:23 PM, Darin Fisher <da...@chromium.org> wrote:


On Tue, Aug 23, 2016 at 4:30 AM, Kentaro Hara <har...@chromium.org> wrote:
Hi

Let me ask a couple of quick questions about Blink-Mojo bindings:

1) Blink sometimes uses a per-frame interface provider but sometimes use a global interface provider. Specifically, we mix the following two patterns. Do you have any preference on which pattern Blink should use?

  frame.interfaceProvider()->getInterface(&m_service);
  Platform::current()->interfaceProvider()->getInterface(&m_service);


Some services need to know what browser tab the client is associated with. For example, the WebSocket backend needs to know how to deal with certificate errors, and the user may have previously accepted a bad certificate but only for a particular tab.

With Chrome IPC, we plumb this context using identifiers called "routing IDs" or "render frame IDs." Instead, of plumbing those identifiers into Blink, we take advantage of a Mojo pipe being effectively an identifier, and then just select the appropriate Frame's InterfaceProvider.

The above makes it easy for Mojom interfaces to mimic the interfaces exposed by WebFrameClient and Platform, and indeed the same "sometimes the embedder needs to know context about which Frame something is happening in" reasoning explains why WebFrameClient exists.

Ah, got it. Specifically, I was looking at this CL and wondering which one BudgetService should use. Given that BudgetService is associated with a frame, it should use a per-frame InterfaceProvider instead of the platform-wide InterfaceProvider.

 

 
2) Blink sometimes sets a connection error handler but not always. Should Blink set a connection error handler always? What happens if Blink forgets to set a connection error handler?

  m_service.set_connection_error_handler(...);

There are two Mojo bindings classes: mojo::Binding and mojo::StrongBinding. If you use the later, then it implicitly sets up a connection error handler and deletes the bound interface implementation when a connection error occurs. Sometimes, you will want more control over what happens when a connection error occurs, so you can use mojo::Binding instead and monitor the connection error yourself.

If you use mojo::Binding and do not observe connection error, then upon connection error, you will stop receiving incoming method calls and any outgoing method calls will just be eaten silently.

Thanks, makes sense.

 
-Darin

 

Thanks!

--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CABg10jz4sAg-CNpp2U0Vi1oSQ5TkrwKROwAv%3Dq9MKF7jJqz0Ww%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.
To post to this group, send email to chromi...@chromium.org.

Makoto Shimazu

unread,
Aug 23, 2016, 9:30:54 PM8/23/16
to Kentaro Hara, Darin Fisher, chromium-mojo
Drive-by question.

On Wed, Aug 24, 2016 at 12:01 AM Kentaro Hara <har...@chromium.org> wrote:
Thanks Darin!

On Tue, Aug 23, 2016 at 11:23 PM, Darin Fisher <da...@chromium.org> wrote:


On Tue, Aug 23, 2016 at 4:30 AM, Kentaro Hara <har...@chromium.org> wrote:
Hi

Let me ask a couple of quick questions about Blink-Mojo bindings:

1) Blink sometimes uses a per-frame interface provider but sometimes use a global interface provider. Specifically, we mix the following two patterns. Do you have any preference on which pattern Blink should use?

  frame.interfaceProvider()->getInterface(&m_service);
  Platform::current()->interfaceProvider()->getInterface(&m_service);


Some services need to know what browser tab the client is associated with. For example, the WebSocket backend needs to know how to deal with certificate errors, and the user may have previously accepted a bad certificate but only for a particular tab.

With Chrome IPC, we plumb this context using identifiers called "routing IDs" or "render frame IDs." Instead, of plumbing those identifiers into Blink, we take advantage of a Mojo pipe being effectively an identifier, and then just select the appropriate Frame's InterfaceProvider.

The above makes it easy for Mojom interfaces to mimic the interfaces exposed by WebFrameClient and Platform, and indeed the same "sometimes the embedder needs to know context about which Frame something is happening in" reasoning explains why WebFrameClient exists.

Ah, got it. Specifically, I was looking at this CL and wondering which one BudgetService should use. Given that BudgetService is associated with a frame, it should use a per-frame InterfaceProvider instead of the platform-wide InterfaceProvider.

 

 
2) Blink sometimes sets a connection error handler but not always. Should Blink set a connection error handler always? What happens if Blink forgets to set a connection error handler?

  m_service.set_connection_error_handler(...);

There are two Mojo bindings classes: mojo::Binding and mojo::StrongBinding. If you use the later, then it implicitly sets up a connection error handler and deletes the bound interface implementation when a connection error occurs. Sometimes, you will want more control over what happens when a connection error occurs, so you can use mojo::Binding instead and monitor the connection error yourself.

If you use mojo::Binding and do not observe connection error, then upon connection error, you will stop receiving incoming method calls and any outgoing method calls will just be eaten silently.

Thanks, makes sense.


What will happen if set_connection_error_handler is used for mojo::StrongBinding? If I want to handle the error manually (ex: terminating worker context), should I use mojo::Binding instead of mojo::StrongBinding and delete the interface object manually? Or it's no problem to use mojo::StrongBinding with set_connection_error_handler?

# Currently I'm working on mojofication for the service worker:)

 
-Darin

 

Thanks!

--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-moj...@chromium.org.

To post to this group, send email to chromi...@chromium.org.

Yuzhu Shen

unread,
Aug 24, 2016, 2:22:43 AM8/24/16
to Makoto Shimazu, Kentaro Hara, Darin Fisher, chromium-mojo
On Tue, Aug 23, 2016 at 6:30 PM, Makoto Shimazu <shi...@chromium.org> wrote:
Drive-by question.

On Wed, Aug 24, 2016 at 12:01 AM Kentaro Hara <har...@chromium.org> wrote:
Thanks Darin!

On Tue, Aug 23, 2016 at 11:23 PM, Darin Fisher <da...@chromium.org> wrote:


On Tue, Aug 23, 2016 at 4:30 AM, Kentaro Hara <har...@chromium.org> wrote:
Hi

Let me ask a couple of quick questions about Blink-Mojo bindings:

1) Blink sometimes uses a per-frame interface provider but sometimes use a global interface provider. Specifically, we mix the following two patterns. Do you have any preference on which pattern Blink should use?

  frame.interfaceProvider()->getInterface(&m_service);
  Platform::current()->interfaceProvider()->getInterface(&m_service);


Some services need to know what browser tab the client is associated with. For example, the WebSocket backend needs to know how to deal with certificate errors, and the user may have previously accepted a bad certificate but only for a particular tab.

With Chrome IPC, we plumb this context using identifiers called "routing IDs" or "render frame IDs." Instead, of plumbing those identifiers into Blink, we take advantage of a Mojo pipe being effectively an identifier, and then just select the appropriate Frame's InterfaceProvider.

The above makes it easy for Mojom interfaces to mimic the interfaces exposed by WebFrameClient and Platform, and indeed the same "sometimes the embedder needs to know context about which Frame something is happening in" reasoning explains why WebFrameClient exists.

Ah, got it. Specifically, I was looking at this CL and wondering which one BudgetService should use. Given that BudgetService is associated with a frame, it should use a per-frame InterfaceProvider instead of the platform-wide InterfaceProvider.

 

 
2) Blink sometimes sets a connection error handler but not always. Should Blink set a connection error handler always? What happens if Blink forgets to set a connection error handler?

  m_service.set_connection_error_handler(...);

There are two Mojo bindings classes: mojo::Binding and mojo::StrongBinding. If you use the later, then it implicitly sets up a connection error handler and deletes the bound interface implementation when a connection error occurs. Sometimes, you will want more control over what happens when a connection error occurs, so you can use mojo::Binding instead and monitor the connection error yourself.

If you use mojo::Binding and do not observe connection error, then upon connection error, you will stop receiving incoming method calls and any outgoing method calls will just be eaten silently.

Thanks, makes sense.


What will happen if set_connection_error_handler is used for mojo::StrongBinding? If I want to handle the error manually (ex: terminating worker context), should I use mojo::Binding instead of mojo::StrongBinding and delete the interface object manually? Or it's no problem to use mojo::StrongBinding with set_connection_error_handler?

It is okay to use StrongBinding::set_connection_error_handler(). This handler will be called on connection error, the object will be deleted after the handler returns.

# Currently I'm working on mojofication for the service worker:)

 
-Darin

 

Thanks!

--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.



--
Kentaro Hara, Tokyo, Japan

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.

--
You received this message because you are subscribed to the Google Groups "chromium-mojo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-mojo+unsubscribe@chromium.org.

To post to this group, send email to chromi...@chromium.org.
Reply all
Reply to author
Forward
0 new messages