PSA: C++ bindings: InterfaceFactory and ApplicationConnection are dead

[Viet-Trung Luu]

(OK, not bindings per se, but code in mojo/public/cpp/application....)

You now get a ServiceProviderImpl in your ApplicationDelegate::ConfigureIncomingConnection() instead of an ApplicationConnection. Instead of implementing InterfaceFactory<Foo> and calling AddService() with your object, just call AddService() with a suitable lambda. See mojo/public/cpp/application/service_provider_impl.h for details.

The use of ApplicationConnection for holding information about a connection has been superseded by ConnectionContext, which just holds data.

Relatedly, ConnectToApplication()'s (etc.) exposed_services parameter is going away soon; it has already been neutered, to if you tried to use it, you'd be sad. (With all of the above changes, you should no longer have much opportunity to be sad, since you shouldn't have easy access to exposed_services anymore.)

[Adam Barth]

Is there a recommended way to expose services from the connector to the connectee now?

Mozart uses a similar pattern for createView:

for https://github.com/domokit/mojo/blob/master/mojo/services/ui/views/interfaces/view_provider.mojom#L30

Maybe the recommendation is to use subsidiary interfaces like ViewProvider rather than using Application itself to exchange service providers in both directions.

Adam

[Viet-Trung Luu]

Yes.

First, you should ask the question of whether you want a service provider in the other direction. (Using such a service provider means thinking about naming/namespacing issues[*] -- which side's idea of naming services should that service provider adhere to?)

In general, I would guess that the answer is you don't want a service provider in the opposite direction. Instead, the connector can connect to a specific service on the connectee, and provide typed connections as required.[**] Of course, if you really want to give a service provider, you can do that too.

E.g.,

interface Foo {

// Instead of having the connectee request a Bar from the connector,

// the connector can connect to Foo and give the the connectee a Bar.

ProvideBar(Bar bar);

// If the connectee needs general services, it can also do something like:

ProvideMoarServices(MoarServices moar_services);

// Or even a ServiceProvider if you really need (at the risk of namespacing confusion):

ProvideAServiceProvider(ServiceProvider sp);

};

interface MoarServices {

GiveMeABaz(Baz& baz);

GiveMeAQuux(Quux& quux);

};

[*] Despite the appearance of there being a global namespace for service names, there isn't one. When you connect to an application at http://example.com/foo.mojo, the names by which you request services from foo.mojo are in foo.mojo's namespace (i.e., names according to foo.mojo).

Now, exposed_services (opposite-direction service provider) posed a problem. You might think that the namespace would be the connector's (i.e., the app connecting to foo.mojo's), but this makes it basically useless (how is foo.mojo expected to know anything about the connector's service namespace?). Therefore, it has to be in foo.mojo's namespace, but no one ever understood this....

[**] This pattern clears up the namespacing confusion. Names/types are all in the "connectee's namespace".

 

Adam

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

[Adam Barth]

[+jeffbrown]

That's interesting.  I wonder if we should change how createView works in Mozart in light of these issues.

Adam

 

[Jeff Brown]

Yes, we should probably change CreateView.  It was modeled on Application for consistency but AFAIK no one is using the reverse service provider today.

These dependencies are easy to invert without loss of generality.

Jeff.

[Viet-Trung Luu]

CreateView has been changed.

--