Location of cross-module mojom files

[John Abd-El-Malek]

(sending to chromium-mojo, platform-architecture-dev, and top level content owners. This should cover the set of folks working in this area so we can reach consensus). Apologies for the length of the email!

Recently the question came up of where we put mojom files for interfaces that are called by the renderer process and implemented in chrome. This is going to come up more frequently as chrome IPCs are converted to mojo, and as web platform implementations move from content/renderer to third_party/WebKit.

<history>

Let's start by looking at the current situation today.

First, for many web platform features that require the user's permission or needs to get out of the sandbox, the feature code in Blink would talk to content via a WebFeature delegate interface declared in third_party/WebKit/public/platform/modules/. This would be implemented in content/render, and it would send an IPC to code in content/browser. That code would then talk to chrome through a delegate interface (sometimes a specific one, or often a general one like ContentBrowserClient).

Second, for browser features that interact with Blink, we have tried to keep knowledge about them outside of content where possible. An example is autofill. Blink calls WebAutofillClient that is implemented by src/components/autofill/content/renderer. It then IPCs to components/autofill/content/browser.

A distinction for the above two cases is that for the former, a chromium embedder has to look for interfaces in content/public to see their responsibility. In the second case, they also have to look at third_party/WebKit/public/web. For both of these cases though, it must be confusing for new embedders of chromium. These directories contain both interfaces that are used to call content and Blink, but also interfaces that have to be implemented by the embedder (of chromium) and the embedder of Blink (which is content).

This is a lot of layers. Note that when the content split was done years ago, we consciously chose a few design decisions:

-IPCs shouldn't span chrome/content layer. The thinking then was that we want to have a proper API that separates the two modules.

-content would not wrap interfaces from modules that sit below it in the stack. i.e. a chromium embedder would call/implement net/Blink/etc... interfaces directly where needed.

</history>

So a few questions come up now:

1) Since Mojo IPCs are still IPCs, do we want to change our policy and allow mojom interfaces to span processes?

-I believe the answer should be yes, since we are trying to cut down layers and remove busy work.

2) If the answer to 1) is yes, here do we put the mojom files?

There are a few sub questions here:

a) When Blink calls a chromium embedder, where do the mojom files live?

-it seems it would be silly for them to be in content/public, since in our (Chrome) case, this is communication between Blink and chrome and the content module isn't involved. That argues for putting them in third_party/WebKit/public/...

b) Should we enforce that all mojom interfaces that are implemented by chromium embedders have to be inside content/public/common/... and third_party/WebKit/...?

-i.e. chromium embedders need to be able to look in one or two places at most to see what their responsibility is as an embedder. They can't be expected to also hunt for mojom files in subdirectories of src/components, src/device etc... as well.

c) Should we clearly denote which mojom files are implemented by content vs chromium embedders in Blink's public directory?

-Since we will probably end up with a lot of mojoms in Blink's public directory, it would be good to have a way to make it easy for chromium embedders to look at a small directory to see what their responsibility is, and not have them also see the mojoms that are implemented by content.

Thanks

[Darin Fisher]

I'd recommend putting service interfaces alongside service implementation. Reason: There may be N clients but there will typically only be 1 implementation. Plus, I think it leads to an organization of code that is pretty rational. If you depend on services A, B and C, then you'd expect to have #include dependencies on A, B and C.

I think this also implies factoring services out of src/{chrome,content}. Is that too big of a change?

-Darin

[Ken Rockot]

I also like having mojoms alongside the service implementations. I don't think there's a problem with the model where //foo implementation lives along side //foo/public, and anyone (*anyone!*) is allowed to consume anything (*anything!*) from //foo/public. The mojom would live under public/interfaces or public/mojom or whatever.

In the rare cases where we have N > 1 implementations of the same service interface, I think it can be addressed on a case by case basis as there's probably not a good one-size-fits-all solution there.

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CAP0-Qpu1_AgqEKNz7CyPdvbbdEg_dmxKfTq5FiWPcKhGid%2B79g%40mail.gmail.com.

[John Abd-El-Malek]

That makes sense for low-level services, i.e. things like file service, network service, etc... 

Most of the IPCs though are specific, and we have one implementation and one caller. i.e. what about all the Chrome infobars for web platform features? They are implemented in src/chrome/browser, and it's specific to Chrome's UI. We can't have content or blink depend on chrome. So we would move it to another directory (which can't depend on chrome), and then we'd have a delegate interface to chrome's UI? That seems like the kind of extra layering that we want to avoid.

On Thu, Jan 21, 2016 at 11:57 AM, Darin Fisher <da...@chromium.org> wrote:

[Sam McNally]

I'm in the interfaces near service implementations camp.

For interfaces implemented in chrome and consumed by blink, could we think of it as a client interface and put the mojom in a public directory corresponding to the consumer?

--
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.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-mojo/CALhVsw1%3DwKAzDUxF%2B2mkAXigHu6zTrKG9-i7_dbVL1-ya6K03g%40mail.gmail.com.

[Darin Fisher]

Yeah, John and I chatted in the hallway yesterday and arrived at the same idea. A module can expose interfaces other can use to access it, and a module may also expose interfaces expressing it's dependencies (in dependency injection fashion). Blink should have both.

-Darin

[John Abd-El-Malek]

Sounds good, thanks all. My email was about delegate interfaces from Blink, but it must have been ambiguous :)

Summary: low-level services that Blink (and other modules) depend on, like networking, file system etc... will live beside the implementations. These low-level services can be thought of to live "below" Blink, content etc... in the stack. Any interface that Blink or content call which needs to be implemented by a chromium embedder will live in the public directory of Blink or content respectively.

[Kentaro Hara]

FWIW, I created a list of components in content/renderer/, which need to be converted from the old IPC to Mojo and then migrated into Blink's platform/.

https://docs.google.com/spreadsheets/d/1McxT38rVZFj7mjmXPr-NDLXREBPcHqZcBBW47iKc920/edit#gid=1061842243

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/platform-architecture-dev/CALhVsw01C%2B6hYnMnKYhK_E_AFk-9vONHF10ei0qO7KGfQBA_Ng%40mail.gmail.com.

--

Kentaro Hara, Tokyo, Japan