Is there a design doc for this?  For the WebUI usage of networking private, I imagine this could be a drop-in replacement (just expose the JS bindings through mojo instead of the extensions binding system), but that approach won't work for actual extensions usage.

I didn't write a DD, it didn't seem necessary, I hope the results to be self explanatory.

There is a tangential DD for using mojo in WebUI:
https://docs.google.com/document/d/1IVAX02m1biR-Jbw_eF5oBKeFsxjLocXtJLJ5cphgNmo/edit

I'm not sure what you mean by "drop-in replacement". For networkingPrivate, the plan is:

1. Create a .mojom interface for a new service (e.g. cros_entwork_config.mojom). The result of this effort should make that much, much, easier since we already have a very similar API in networking_private.idl (but it probably won't quite be identical).

2. Implement the service. This will be similar to the extension API implementation i.e. networking_private_chromeos.cc.

3. Use that service in Ash C++ code to eliminate Ash dependencies on the Shill DBus interface.

4. Use the cros_network_config mojo interface in WebUI (settings and network config dialogs) instead of the networkingPrivate extension API.

5. Deprecate networkingPriavte! We will maintain networkingOnc (a subset) for kiosk apps for a while.

Thanks, stevenjb@!  I think this makes perfect sense for an API that is only ever used in WebUI.  My main hangup is that networkingPrivate is also the basis for networking.onc - do we have a plan for that?  I'd like to make sure we avoid having duplicate implementations for behavior that is otherwise identical.  Or is the plan to effectively fork networkingPrivate and networking.onc?

Note that I have no concerns for an API that is not shared between extensions and WebUI, such as quickUnlockPrivate, where the mojo version would completely replace the extension version.

For better or for worse, this will effectively be forking chrome.networking.onc and cros_network_config.mojom, although they will continue to use the same low level implementation layer.

Basically it will look like:

Kiosk app -> chrome.networking.onc -> chromeos::NetworkHandler -> Shill
(Ash UI | WebUI) -> cros_network_config.mojom -> chromeos::NetworkHandler -> Shill

The networking.onc and cros_network_config.mojom implementations will both be in the Chrome process, with a single NetworkHandler instance talking to Shill. (Today, in Mash/OopAsh, the Ash process has its own NetworkHandler instance, also talking to Shill, which has consistency issues).

When completed, we will be able to think about chrome.networking.onc kind of like e.g.  chrome.app.window. It does similar things to mojo APIs used between Ash and Chrome, and uses similar C++ classes in the implementation, but is not directly tied to them.