Mojo: Expose untyped associated endpoints through public API

Mojo: Expose untyped associated endpoints through public API

This CL exposes ScopedInterfaceEndpointHandle through
AssociatedInterfaceRequest and AssociatedInterfacePtrInfo
to allow for unbinding and rebinding associated endpoints
to arbitrary interface types.

BUG=612500
R=yzshen@chromium.org

Committed: https://crrev.com/f4698a23e30ce832bf2c728d2444f72019ddf1a1
Cr-Commit-Position: refs/heads/master@{#394306}

[Ken Rockot(use gerrit already), 2016-05-17 20:36:18]

Please take a look. I decided to make AssociatedInterfacePtr and
AssociatedInterfaceRequest look similar to their non-associated counterparts,
except I used PassHandle instead of PassMessagePipe on the request type.

[yzshen1, 2016-05-17 21:37:19]

On 2016/05/17 20:36:18, Ken Rockot wrote:
> Please take a look. I decided to make AssociatedInterfacePtr and
> AssociatedInterfaceRequest look similar to their non-associated counterparts,
> except I used PassHandle instead of PassMessagePipe on the request type.

Based on our last discussion, I think you are planning to use an "associated
GenericInterface" in the mojom definition and extract the handle of it to be
rebound with a specific associated interface ptr/binding, right?

I am thinking whether it makes sense to introduce "associated handle". Just like
InterfaceProvider where we define:
GetInterface(string interface_name, handle<message_pipe> pipe);

Maybe we can enable:
GetInterface(string interface_name, associated handle<message_pipe> pipe);
Correspondingly, we can name the C++ object ScopedAssociatedMessagePipeHandle.

But I am not sure, because I tried to avoid the idea that "associated" is a
"message pipe"/edk level thing. Maybe we simply use "associated handle"?

WDYT? Thanks!

[Ken Rockot(use gerrit already), 2016-05-17 21:44:41]

On 2016/05/17 at 21:37:19, yzshen wrote:
> On 2016/05/17 20:36:18, Ken Rockot wrote:
> > Please take a look. I decided to make AssociatedInterfacePtr and
> > AssociatedInterfaceRequest look similar to their non-associated
counterparts,
> > except I used PassHandle instead of PassMessagePipe on the request type.
> 
> Based on our last discussion, I think you are planning to use an "associated
GenericInterface" in the mojom definition and extract the handle of it to be
rebound with a specific associated interface ptr/binding, right?
> 
> I am thinking whether it makes sense to introduce "associated handle". Just
like InterfaceProvider where we define:
> GetInterface(string interface_name, handle<message_pipe> pipe);
> 
> Maybe we can enable:
> GetInterface(string interface_name, associated handle<message_pipe> pipe);
> Correspondingly, we can name the C++ object ScopedAssociatedMessagePipeHandle.
> 
> But I am not sure, because I tried to avoid the idea that "associated" is a
"message pipe"/edk level thing. Maybe we simply use "associated handle"?
> 
> WDYT? Thanks!

Yeah I think we discussed this possibility a while ago. It might be nice, but it
requires a lot more changes, and the payoff is still unclear. If we built it I
think the usage of "ScopedAssociatedMessagePipeHandle" would end up looking a
lot like a ScopedInterfaceEndpointHandle, so maybe we can start with something
small like this CL and iterate toward associated handle<message_pipe> if it
turns out to be a common pattern. WDYT?

[yzshen1, 2016-05-17 21:50:48]

Okay. LGTM with one nit.

https://codereview.chromium.org/1991463002/diff/1/mojo/public/cpp/bindings/sc...
File mojo/public/cpp/bindings/scoped_interface_endpoint_handle.h (right):

https://codereview.chromium.org/1991463002/diff/1/mojo/public/cpp/bindings/sc...
mojo/public/cpp/bindings/scoped_interface_endpoint_handle.h:32:
ScopedInterfaceEndpointHandle(
Does it make sense to make this private and MultiplexRouter a friend?

[Ken Rockot(use gerrit already), 2016-05-17 22:35:04]

Thanks!

https://codereview.chromium.org/1991463002/diff/1/mojo/public/cpp/bindings/sc...
File mojo/public/cpp/bindings/scoped_interface_endpoint_handle.h (right):

https://codereview.chromium.org/1991463002/diff/1/mojo/public/cpp/bindings/sc...
mojo/public/cpp/bindings/scoped_interface_endpoint_handle.h:32:
ScopedInterfaceEndpointHandle(
On 2016/05/17 at 21:50:48, yzshen1 wrote:
> Does it make sense to make this private and MultiplexRouter a friend?

Done

[Ken Rockot(use gerrit already), 2016-05-17 22:35:05]

The CQ bit was checked by rockot@chromium.org

[Ken Rockot(use gerrit already), 2016-05-17 22:35:05]

The patchset sent to the CQ was uploaded after l-g-t-m from yzshen@chromium.org
Link to the patchset: https://codereview.chromium.org/1991463002/#ps20001
(title: " ")

[commit-bot: I haz the power, 2016-05-17 22:35:44]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1991463002/20001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1991463002/20001

[commit-bot: I haz the power, 2016-05-18 01:16:14]

Committed patchset #2 (id:20001)

[commit-bot: I haz the power, 2016-05-18 01:18:15]

Description was changed from

==========
Mojo: Expose untyped associated endpoints through public API

This CL exposes ScopedInterfaceEndpointHandle through
AssociatedInterfaceRequest and AssociatedInterfacePtrInfo
to allow for unbinding and rebinding associated endpoints
to arbitrary interface types.

BUG=612500
R=yzshen@chromium.org
==========

to

==========
Mojo: Expose untyped associated endpoints through public API

This CL exposes ScopedInterfaceEndpointHandle through
AssociatedInterfaceRequest and AssociatedInterfacePtrInfo
to allow for unbinding and rebinding associated endpoints
to arbitrary interface types.

BUG=612500
R=yzshen@chromium.org

Committed: https://crrev.com/f4698a23e30ce832bf2c728d2444f72019ddf1a1
Cr-Commit-Position: refs/heads/master@{#394306}
==========

[commit-bot: I haz the power, 2016-05-18 01:18:16]

Patchset 2 (id:??) landed as
https://crrev.com/f4698a23e30ce832bf2c728d2444f72019ddf1a1
Cr-Commit-Position: refs/heads/master@{#394306}