There are many ways to create a message pipe. These were mostly introduced ad hoc for the sake of convenience, less typing, etc. Per discussion with other team members, we should try to reduce this API surface. This includes both public Mojo bindings API as well as service manager client libraries.
There are a few redundant patterns I see at a glance, and I would like to eliminate all of them in the interest of API simplicity:
1) Methods like Foo(InterfaceRequest) having companion overloads
like Foo(InterfacePtr*). This is always unnecessary, as the caller
can trivially compose a call to MakeRequest with the first signature.
2) Similar to above but for generic ScopedMessagePipeHandles. Public APIs
which take generic handles should be limited to ones which bind arbitrary
interfaces by name (or, of course, ones which use a message pipe for
raw I/O i.e. no bindings interface).
3) mojo::Binding<T>::CreateInterfacePtrAndBind() is redundant and calls can
trivially be replaced with Bind(MakeRequest(&ptr))
The latter case requires extra lines of code to adapt. i.e.
return binding_.CreateInterfacePtrAndBind()
becomes
FooPtr ptr;
binding_.Bind(MakeRequest(&ptr));
return ptr;
But I don't feel this justifies the extra method on Binding. Furthermore, sometimes it's useful to avoid binding an InterfacePtr and instead bind only an InterfacePtrInfo. Having MakeRequest be the sole API (which can be overloaded for each of InterfacePtr*, InterfacePtrInfo*, AssociatedInterfacePtr* and AssociatedInterfacePtr* args) reduces the total API surface required across different binding primitives.
Comment 1 by roc...@chromium.org
, May 11 2017