Add abstract BluetoothProfile class

device/bluetooth/bluetooth_profile.h

Index: device/bluetooth/bluetooth_profile.h
diff --git a/device/bluetooth/bluetooth_profile.h b/device/bluetooth/bluetooth_profile.h
new file mode 100644
index 0000000000000000000000000000000000000000..8f535dd37482ed02d52ec976fe138480aac74e3c
--- /dev/null
+++ b/device/bluetooth/bluetooth_profile.h
@@ -0,0 +1,98 @@
+// 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 DEVICE_BLUETOOTH_BLUETOOTH_PROFILE_H_
+#define DEVICE_BLUETOOTH_BLUETOOTH_PROFILE_H_
+
+#include <string>
+
+#include "base/callback.h"
+#include "base/memory/ref_counted.h"
+
+namespace device {
+
+class BluetoothSocket;
+
+// BluetoothProfile represents an implementation of either a client or server
+// of a particular specified profile (aka service or protocol in other
+// standards).
+//
+// Profile implementations are created by registering them through the static
+// BluetoothProfile::Register() method and are always identified by a UUID
+// which in any method may be specified in the short or long form.
+//
+// The lifecycle of BluetoothProfile instances is managed by the implementation
+// but they are guaranteed to exist once provided to a Register() callback until
+// the instance's Unregister() method is called, so others may hold on to
+// pointers to them.
+class BluetoothProfile {
+ public:
+  // Register an implementation of the profile with UUID |uuid|, the
+  // corresponding profile object will be created and returned by
+  // |callback|. If the profile cannot be registered, NULL will be passed.
+  //
+  // This pointer is not owned by the received, but will not be freed unless
+  // its Unregister() method is called.
+  typedef base::Callback<void(BluetoothProfile*)> ProfileCallback;
+  static void Register(const std::string& uuid,
+                       const ProfileCallback& callback);
+
+  // Unregister the profile, once called any pointers to the profile should be
+  // discarded.
+  virtual void Unregister() = 0;
+
+  // Set the connection callback for the profile to |callback|, any successful
+  // connection initiated by BluetoothDevice::ConnectToProfile() or incoming
+  // connections from devices, will have a BluetoothSocket created and passed
+  // to this callback.
+  //
+  // The socket will be closed when all references are released; none of the
+  // BluetoothProfile, or BluetoothAdapter or BluetoothDevice objects are
+  // guaranteed to hold a reference so this may be outlive all of them.

[youngki, 2013/04/10 01:28:49]

s/may be outlive/may outlive/

[youngki, 2013/04/10 19:39:05]

Make sure to fix this before committing.

[keybuk, 2013/04/17 22:38:35]

Done.

+  typedef base::Callback<void(scoped_refptr<BluetoothSocket>)> SocketCallback;
+  virtual void SetConnectionCallback(const SocketCallback& callback) = 0;

[youngki, 2013/04/10 01:28:49]

Since bluetooth.onConnection is an event and we are adding listeners to it, we
cannot actually have the callbacks here; instead we should communicate through
BluetoothAdapter::Observer, and let it dispatch the bluetooth.onConnection event
to the listeners. So we should have

BluetoothAdapter::Observer::OnConnected(scoped_refptr<BluetoothSocket> socket);

And somehow when the socket is made we should call OnConnected() of the
bluetooth adapter observers with the socket.

[youngki, 2013/04/10 16:38:19]

Or, if we want to keep this interface, we could actually pass
BluetoothAdapter::CallOnConnectionObserverMethod(scoped_refptr<BluetoothSocket>)
as a callback and have that function call the observer method. Maybe that's
easier to implement.

+
+  // Human readable name of the Profile, e.g. "Health Device".

[youngki, 2013/04/10 01:28:49]

So all the below methods are for the profiles exported from the adapter itself?
Does it mean that if I want to register a profile from a remote device, I do not
need to call the below methods?

+  // Exported in the adapter's SDP or GATT tables where relevant.
+  virtual void SetName(const std::string& name) = 0;
+  virtual std::string GetName() const = 0;
+
+  // RFCOMM channel used by the profile.
+  // Exported in the adapter's SDP or GATT tables where relevant.
+  virtual void SetChannel(uint16 channel) = 0;
+  virtual uint16 GetChannel() const = 0;
+
+  // L2CAP PSM number.
+  // Exported in the adapter's SDP or GATT tables where relevant.
+  virtual void SetPSM(uint16 psm) = 0;
+  virtual uint16 GetPSM() const = 0;
+
+  // Specifies whether pairing (and encryption) is required to be able to
+  // connect. Defaults to false.
+  virtual void SetRequireAuthentication(bool require_authentication) = 0;
+  virtual bool GetRequireAuthentication() const = 0;
+
+  // Specifies whether user authorization is required to be able to connect.
+  // Defaults to false.
+  virtual void SetRequireAuthorization(bool require_authorization) = 0;
+  virtual bool GetRequireAuthorization() const = 0;
+
+  // Implemented version of the profile.
+  // Exported in the adapter's SDP or GATT tables where relevant.
+  virtual void SetVersion(uint16 version) = 0;
+  virtual uint16 GetVersion() const = 0;
+
+  // Implemented feature set of the profile.
+  // Exported in the adapter's SDP or GATT tables where relevant.
+  virtual void SetFeatures(uint16 features) = 0;
+  virtual uint16 GetFeatures() const = 0;
+
+ private:
+  BluetoothProfile();
+  virtual ~BluetoothProfile();

[youngki, 2013/04/11 18:33:41]

Shouldn't the destructor be protected? Otherwise the object won't get
destroyed...

[keybuk, 2013/04/17 22:38:35]

Unregister() should be doing the deletion - so it seems appropriate for it to be
Private

[youngki, 2013/04/19 16:26:36]

I think you are trying to follow RefCounted model where the destructor is
private and RefCounted<>::Release deletes itself, right? Could you explain what
is the benefit of using Unregister() instead of destructor to delete the object?
Are we trying to count the references to the object?

[keybuk, 2013/04/19 17:58:18]

I don't like patterns where you get an object via a method, but are expected to
"delete" it - e.g

obj = Foo::Register();
delete obj;

delete is fine if you used new:

obj = new Foo;
delete obj;

but for the former, I tend to prefer:

obj = Foo::Register();
obj->Unregister();

I'm totally okay to go with delete if that's Google style, but working on the
D-Bus code (which uses Unregister() or Detach() like this) led me to believe I
was already ;)

[youngki, 2013/04/19 18:20:39]

sounds good

+};
+
+}  // namespace device
+
+#endif /* DEVICE_BLUETOOTH_BLUETOOTH_PROFILE_H_ */