Add Mojo interfaces for out-of-process proxy resolver.

net/interfaces/proxy_resolver_service.mojom

+// Copyright 2015 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+// Put Mojo definitions into their own namespace to avoid collisions with C++
+// definitions.
+// TODO(amistry): Resolve the conflict between these two sets of definitions.
+module net.interfaces;
+
+import "host_resolver_service.mojom";
+
+// Partial mirror of net::LoadState. Only contains values possible by the
+// proxy resolver.
+enum LoadState {
+  RESOLVING_PROXY_FOR_URL,
+  RESOLVING_HOST_IN_PROXY_SCRIPT,
+};
+
+interface ProxyResolverService {
+  SetPacScript(string data) => (int32 result);
+
+  // Use a ProxyResolveRequestClient instead of returning a result so we can

[eroman, 2015/02/03 04:53:29]

I see, you are using "ResolveClient" throughout.

I am still in favor of "ResolverClient" so less changes from the service name.
Or alternately naming it similar to the method that starts it
"GetProxyForUrlClient" or something. Just for more consistency in deriving the
names.

[Anand Mistry (off Chromium), 2015/02/03 06:27:22]

Changed to "Resolver" everywhere. I agree it's better.

+  // receive load state updates and cancel in-flight requests by destroying the
+  // client.
+  // TODO(amistry): Add BoundNetLog.
+  GetProxyForUrl(string url, ProxyResolveRequestClient client);
+};
+
+interface ProxyResolveRequestClient {
+  ReportResult(int32 error, string? pac_string);

[eroman, 2015/02/03 04:53:29]

I can certainly understand wanting to return a PAC string as the result, and
don't disagree with this decision for a first version.

However long term I think it would be better for the result to be a structure
ProxyList (a sequence of "scheme", "host", "port").

This way the parsing of the PAC string can also be done in the sandboxed
process.

[Anand Mistry (off Chromium), 2015/02/03 06:27:22]

Looks straight forward. Might as well change it right now.

+  UpdateLoadState(LoadState load_state);

[eroman, 2015/02/03 04:53:29]

Can you give some details on how this will work?

Currently if memory serves the load state is used for printing the status at the
bottom of the page while loading. And is determined by polling and a heuristic
to determine which state takes precedence.

Do you want to track it accurately and hence have this callback invoked whenever
it changes?

It might be simpler to instead have a request to get the load state and not
track it.

[Anand Mistry (off Chromium), 2015/02/03 06:27:22]

So, I had an explanation on how this would work... until I took another look at
the v8 tracing proxy implementation :(. It is possible to implement accurately
by polling for state changes whenever a DNS request starts/ends (since we have
no way of associating a proxy request with a DNS request). But that's O(n) on
the number of pending proxy requests. Can I get by and not implement this, or
just lie and always return RESOLVING_PROXY_FOR_URL?
The problem there is ProxyResolver::GetLoadState() is synchronous, so we can't
get it on demand.

[Sam McNally, 2015/02/03 23:51:30]

I think we should punt on LoadState for now.

[eroman, 2015/02/04 01:25:20]

Agreed (punt on LoadState for now), it can return a generic load state.

We will however want it before turning this on by default.

<history>

The main reason for the load state was to distinguish between when the request
is stalled executing javascript, vs when it is waiting for a network dependency
(DNS).

Since in our corp environment we would get hellish "resolving proxy..." and it
wasn't clear that it was actually due to the PAC script doing synchronous DNS
resolves. The load state surfaces this on the page more clearly by indicating it
is a DNS request in proxy script.

</history>

+};
+
+interface ProxyResolverErrorObserver {
+  OnPacScriptError(int32 line_number, string error);
+};
+
+interface ProxyResolverFactory {
+  // TODO(amistry): Add NetLog.
+  CreateResolver(ProxyResolverService& resolver,

[eroman, 2015/02/03 04:53:29]

Forgive me for not being familiar with mojo (yet!)

In C++ code at least non-const references are not idiomatic. What does this
translate to for C++ code?

[Anand Mistry (off Chromium), 2015/02/03 06:27:22]

There are two ends to an interface, the client (calls methods) and service
(implements the methods). When you first create an instance of an interface,
both ends are in-process and you have to pass one of those ends to the other
process. In every case so far where an interface is passed into a method, it's
been passing the client side, so the service is local and the caller is being
given it's side. In this case, the situation is reversed. The client is local
and we're passing the service end to the other process to be connected. We could
have done this like:

CreateResolver(HostResolver hr, Observer ob) => (ProxyResolverService);

This would create everything in the utility process and give us the client side.
But this is asynchronous. Using & gives us the client side right away and lets
us call GetProxyForUrl() right away.

+                 HostResolverService host_resolver,
+                 ProxyResolverErrorObserver error_observer);
+};