chrome.bluetooth API improvements.

device/bluetooth/bluetooth_device.h

 // Copyright (c) 2012 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 DEVICE_BLUETOOTH_BLUETOOTH_DEVICE_H_
 #define DEVICE_BLUETOOTH_BLUETOOTH_DEVICE_H_
 
 #include <string>
 
 #include "base/callback.h"
 #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 {
 
 class BluetoothProfile;
 class BluetoothServiceRecord;
 class BluetoothSocket;
 
 struct BluetoothOutOfBandPairingData;
 
 // BluetoothDevice represents a remote Bluetooth device, both its properties and
@@ skipping 209 matching lines @@
   // were called after the corresponding call to Connect().
   virtual bool IsConnecting() const = 0;
 
   // Returns the services (as UUID strings) that this device provides.
   // TODO(youngki): Rename this to GetProfiles().
   typedef std::vector<std::string> ServiceList;
   virtual ServiceList GetServices() const = 0;
 
   // 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.
   // In the success case this callback is not called.
   typedef base::Callback<void(enum ConnectErrorCode)> ConnectErrorCallback;
 
   // Returns the services (as BluetoothServiceRecord objects) that this device
   // provides.
   typedef ScopedVector<BluetoothServiceRecord> ServiceRecordList;
   typedef base::Callback<void(const ServiceRecordList&)> ServiceRecordsCallback;
@@ skipping 95 matching lines @@
   // all references to the BluetoothSocket are released.  Note that the
   // BluetoothSocket object can outlive both this BluetoothDevice and the
   // BluetoothAdapter for this device.
   virtual void ConnectToService(const std::string& service_uuid,
                                 const SocketCallback& callback) = 0;
 
   // Attempts to initiate an outgoing connection to this device for the profile
   // 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.
   virtual void SetOutOfBandPairingData(
       const BluetoothOutOfBandPairingData& data,
       const base::Closure& callback,
       const ErrorCallback& error_callback) = 0;
 
   // Clears the Out Of Band pairing data for this device.  Exactly one of
   // |callback| or |error_callback| will be run.
   virtual void ClearOutOfBandPairingData(
       const base::Closure& callback,
       const ErrorCallback& error_callback) = 0;
 
  protected:
   BluetoothDevice();
 
   // Returns the internal name of the Bluetooth device, used by GetName().
   virtual std::string GetDeviceName() const = 0;
 
  private:
   // Returns a localized string containing the device's bluetooth address and
   // a device type for display when |name_| is empty.
   base::string16 GetAddressWithLocalizedDeviceTypeName() const;
 };
 
 }  // namespace device
 
 #endif  // DEVICE_BLUETOOTH_BLUETOOTH_DEVICE_H_