PPAPI: Introduce PPB_NetworkProxy_Dev

ppapi/cpp/dev/network_proxy_dev.h

+// Copyright (c) 2013 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.
+
+#ifndef PPAPI_CPP_NETWORK_PROXY_H_
+#define PPAPI_CPP_NETWORK_PROXY_H_
+
+#include <string>
+
+#include "ppapi/c/dev/ppb_network_proxy_dev.h"
+#include "ppapi/cpp/completion_callback.h"
+#include "ppapi/cpp/instance_handle.h"
+
+namespace pp {
+
+class NetworkProxy {
+ public:
+  // Is this worth having?
+  static bool IsAvailable();
+
+  // TODO(dmichael): Sucks to mix string and Var. Would be nice to have both be
+  // string.
+  // TODO(dmichael): There's no way to cancel the request, and there's not even
+  // a resource to release to cause it to be cancelled. Is that okay?
+  static int32_t GetProxyForURL(
+      const InstanceHandle& instance,
+      const std::string& url,

[yzshen1, 2013/06/16 23:49:53]

- I think once Brett suggested me to have the C++ interface as a "thin" wrapper
around the C interface, not the convert the types too much. Maybe we should use
pp::Var for |url| here? Besides, it is more consistent with the output
parameter. What do you think?
(I think we should also look at how the other C++ interfaces deal with this
problem, and do it in a consistent way.)

- WRT cancelling the callback, I think that is fine, it will get cancelled when
the instance goes away.

[dmichael (off chromium), 2013/06/17 21:48:28]

Yes, I wanted them to be consistent. It seems like the simplest for plugins is a
string. But I'm fine with pp::Var...  that's simpler for us, and does keep this
class thinner.

+      const pp::CompletionCallbackWithOutput<Var>& callback); 
+};
+
+}  // namespace pp
+
+#endif  // PPAPI_CPP_NETWORK_PROXY_H_