chrome.bluetooth API improvements.

device/bluetooth/bluetooth_device.h

Index: device/bluetooth/bluetooth_device.h
diff --git a/device/bluetooth/bluetooth_device.h b/device/bluetooth/bluetooth_device.h
index cb1e7ec6994f4ad565b5c5d2a36e9f0d795079ac..8e46cbd34fa358a9c3bf70e757ff0a1820095a53 100644
--- a/device/bluetooth/bluetooth_device.h
+++ b/device/bluetooth/bluetooth_device.h
@@ -11,6 +11,7 @@
 #include "base/memory/ref_counted.h"
 #include "base/memory/scoped_vector.h"
 #include "base/strings/string16.h"
+#include "net/base/net_log.h"
 
 namespace device {
 
@@ -240,7 +241,7 @@ class BluetoothDevice {
 
   // The ErrorCallback is used for methods that can fail in which case it
   // is called, in the success case the callback is simply not called.
-  typedef base::Callback<void()> ErrorCallback;
+  typedef base::Callback<void(const std::string&)> ErrorCallback;
 
   // The ConnectErrorCallback is used for methods that can fail with an error,
   // passed back as an error code argument to this callback.
@@ -356,9 +357,14 @@ class BluetoothDevice {
   // identified by |profile|, on success the profile's connection callback
   // will be called as well as |callback|; on failure |error_callback| will be
   // called.
-  virtual void ConnectToProfile(BluetoothProfile* profile,
-                                const base::Closure& callback,
-                                const ErrorCallback& error_callback) = 0;
+  virtual void ConnectToProfile(
+      BluetoothProfile* profile,
+      scoped_refptr<base::SequencedTaskRunner> ui_task_runner,
+      scoped_refptr<base::SequencedTaskRunner> file_task_runner,
+      net::NetLog* net_log,
+      const net::NetLog::Source& source,

[keybuk, 2014/03/14 21:13:48]

What's the justification for these added parameters?

Are they specific to the resulting BluetoothSocket? In which case why aren't
they part of the BluetoothSocket API?

Or are they specific to the Windows implementation? If not, how would other
platforms, e.g. Chrome OS, use these?

Would different calls to ConnectProfile() expect to pass different parameters
for the task_runners, net_log, source, etc.? Or would they all pass the same?

What about when we move to having ConnectL2cap(), ConnectRfcomm(),
ListenL2cap(), ListenRfcomm() etc. would those need these arguments too?

What about other async functions?

Basically should these be moved towards the original BluetoothAdapter
constructor ?

[rpaquay, 2014/03/14 21:48:09]

That is a good point, the task runners definitely could move to the constructor
(I assume you mean "BluetoothDevice" not "BluetoothAdapter"). As for the
net_log/source, I am not 100% sure, as I don't quite understand their usage at
this point. Other Chrome APPS apis seem to happily pass "NULL, DefaultSource()"
when using TCPSocket, but I have a feeling this is not quite correct either. In
any ways, I think the decision should probably not be made at the "device"
layer, but at a higher layer, hence the need to pass them as parameters
somewhere (here or constructor).

[rpaquay, 2014/03/20 00:48:18]

Done.

+      const base::Closure& callback,
+      const ErrorCallback& error_callback) = 0;
 
   // Sets the Out Of Band pairing data for this device to |data|.  Exactly one
   // of |callback| or |error_callback| will be run.